T TeamFeePay Trust

Control matrix

Every control we operate against ISO/IEC 27001:2022 (93 Annex A controls) and ISO/IEC 27018:2019 (cloud PII processor controls). Search by control ID, title or how we implement it.

ISO/IEC 27001:2022
93 controls

Information security management

The complete Annex A catalogue, grouped by the four 2022 themes: Organizational, People, Physical, Technological.

ISO/IEC 27018:2019
19 controls

Privacy in public clouds (PII processor)

Processor-specific extensions to 27002, plus the 11 PII protection principles in 27018 Annex A.

ISO/IEC 27001:2022 — Annex A

The full 93-control catalogue.

ISO/IEC 27001:2022
Control matrix

Organizational

37 controls
A.5.1 Policies for information security

Information security policy and topic-specific policies are defined, approved by management, published, communicated to relevant personnel and reviewed at planned intervals.

How we implement it

We maintain a top-level Information Security Policy plus topic-specific policies (access control, cryptography, backup, incident response, supplier security, secure development, acceptable use, BCM, data classification). Each is reviewed annually or after a significant change and is approved by the CTO.

Owner: Head of Security Reviewed 11 April 2026
Implemented
A.5.2 Information security roles and responsibilities

Information security roles and responsibilities are defined and allocated according to organisational needs.

How we implement it

Security roles are documented in the ISMS. The CTO is the accountable executive; a Head of Security operates the day-to-day programme; every engineering team has a named security champion.

Owner: Head of Security Reviewed 11 April 2026
Implemented
A.5.3 Segregation of duties

Conflicting duties and areas of responsibility are segregated to reduce opportunities for unauthorised or unintentional modification or misuse of assets.

How we implement it

Production deployments require approval by a second engineer. Payouts and finance operations are split between Engineering and Finance. Audit log review is performed by Security, not by the team being reviewed.

Owner: Head of Security Reviewed 11 April 2026
Implemented
A.5.4 Management responsibilities

Management requires all personnel to apply information security in accordance with the established policy, topic-specific policies and procedures.

How we implement it

Every employment contract references the Information Security Policy. Performance reviews include adherence to security policies. Line managers reinforce expectations during onboarding and at least annually.

Owner: Head of Security Reviewed 11 April 2026
Implemented
A.5.5 Contact with authorities

Appropriate contacts with relevant authorities are maintained.

How we implement it

We maintain documented contacts for the ICO (UK), the National Cyber Security Centre (NCSC), our card-scheme acquirer for PCI matters, and the relevant police cyber units.

Owner: Head of Security Reviewed 11 April 2026
Implemented
A.5.6 Contact with special interest groups

Appropriate contacts with special interest groups, security forums and professional associations are maintained.

How we implement it

Security engineering staff hold memberships with (ISC)² and ISACA, and we subscribe to NCSC CiSP and industry ISACs for early threat intelligence.

Owner: Head of Security Reviewed 11 April 2026
Implemented
A.5.7 Threat intelligence

Information relating to information security threats is collected and analysed to produce threat intelligence.

How we implement it

We ingest threat feeds from CISA KEV, NCSC, our cloud provider and our endpoint vendor. Indicators are correlated against our SIEM and reviewed weekly by the Security team.

Owner: Head of Security Reviewed 11 April 2026
Implemented
A.5.8 Information security in project management

Information security is integrated into project management.

How we implement it

All new projects pass through an architecture review that includes a security checklist. Privacy-impacting projects also undergo a Data Protection Impact Assessment.

Owner: Head of Security Reviewed 11 April 2026
Implemented
A.5.9 Inventory of information and other associated assets

An inventory of information and other associated assets, including owners, is developed and maintained.

How we implement it

We maintain a unified asset inventory covering services, data stores, endpoints and SaaS apps. Each asset has a named owner and classification. The inventory is reconciled monthly.

Owner: Head of Security Reviewed 11 April 2026
Implemented
A.5.10 Acceptable use of information and other associated assets

Rules for the acceptable use and procedures for handling information and other associated assets are identified, documented and implemented.

How we implement it

Our Acceptable Use Policy is published in the staff handbook and acknowledged on hire. It covers credentials, removable media, AI tools, BYOD and travel.

Owner: Head of Security Reviewed 11 April 2026
Implemented
A.5.11 Return of assets

Personnel and other interested parties return all the organisation's assets in their possession upon change or termination of their employment, contract or agreement.

How we implement it

Joiner-Mover-Leaver process triggers asset return on day -1 of departure. Equipment is wiped and inventoried before re-issue or disposal.

Owner: Head of Security Reviewed 11 April 2026
Implemented
A.5.12 Classification of information

Information is classified according to its security needs based on confidentiality, integrity, availability and relevant interested party requirements.

How we implement it

We use a four-tier classification: Public, Internal, Confidential, Restricted. Customer member data is Confidential by default; cardholder data is Restricted.

Owner: Head of Security Reviewed 11 April 2026
Implemented
A.5.13 Labelling of information

An appropriate set of procedures for information labelling is developed and implemented.

How we implement it

Document templates carry the classification in the footer. Source code and infrastructure metadata are tagged with classification labels enforced by CI checks.

Owner: Head of Security Reviewed 11 April 2026
Implemented
A.5.14 Information transfer

Information transfer rules, procedures or agreements are in place for all types of transfer facilities within the organisation and between the organisation and other parties.

How we implement it

Internal transfers go via encrypted, access-controlled channels (Slack EKM, Google Workspace, Drive). External transfers of customer data require encrypted channels and a DPA.

Owner: Head of Security Reviewed 11 April 2026
Implemented
A.5.15 Access control

Rules to control physical and logical access to information and other associated assets are established and implemented based on business and information security requirements.

How we implement it

Access decisions follow least privilege and need-to-know, enforced through role-based access via our identity provider. Access changes are logged and reviewed quarterly.

Owner: Head of Security Reviewed 11 April 2026
Implemented
A.5.16 Identity management

The full life cycle of identities is managed.

How we implement it

Every user has a single Azure AD identity provisioned by HR. Identities are deprovisioned within 1 hour of offboarding via SCIM. No shared accounts; service accounts are non-interactive.

Owner: Head of Security Reviewed 11 April 2026
Implemented
A.5.17 Authentication information

Allocation and management of authentication information is controlled by a management process, including advising personnel on appropriate handling.

How we implement it

Initial passwords are one-time only. Workforce passwords meet NIST SP 800-63B and are stored in a managed password vault. MFA is mandatory.

Owner: Head of Security Reviewed 11 April 2026
Implemented
A.5.18 Access rights

Access rights to information and other associated assets are provisioned, reviewed, modified and removed in accordance with the organisation's topic-specific policy on access control.

How we implement it

Access reviews run quarterly for production systems and bi-annually for SaaS. Privileged access is reviewed monthly.

Owner: Head of Security Reviewed 11 April 2026
Implemented
A.5.19 Information security in supplier relationships

Processes and procedures are defined and implemented to manage the information security risks associated with the use of suppliers' products or services.

How we implement it

Suppliers are risk-tiered. Tier 1 (processes customer data) require a documented security review, DPA, sub-processor disclosure, and an annual reassessment.

Owner: Head of Security Reviewed 11 April 2026
Implemented
A.5.20 Addressing information security within supplier agreements

Relevant information security requirements are established and agreed with each supplier based on the type of supplier relationship.

How we implement it

Our standard supplier contract includes the DPA, SCCs where applicable, breach notification SLAs, audit rights and sub-processor change notification.

Owner: Head of Security Reviewed 11 April 2026
Implemented
A.5.21 Managing information security in the ICT supply chain

Processes and procedures are defined and implemented to manage the information security risks associated with the ICT products and services supply chain.

How we implement it

We pin and verify dependency versions, sign and verify our own artefacts, and run SCA on every build. Supply-chain advisories trigger an SLA-driven triage.

Owner: Head of Security Reviewed 11 April 2026
Implemented
A.5.22 Monitoring, review and change management of supplier services

The organisation regularly monitors, reviews, evaluates and manages change in supplier information security practices and service delivery.

How we implement it

Tier 1 suppliers are reassessed annually; sub-processor changes are reviewed within 30 days; SLA breaches and incidents trigger an out-of-cycle review.

Owner: Head of Security Reviewed 11 April 2026
Implemented
A.5.23 Information security for use of cloud services

Processes for acquisition, use, management and exit from cloud services are established in accordance with the organisation's information security requirements.

How we implement it

Cloud services are procured through Security review. Configuration baselines are enforced via Infrastructure-as-Code. Exit playbooks exist for every Tier 1 cloud service.

Owner: Head of Security Reviewed 11 April 2026
Implemented
A.5.24 Information security incident management planning and preparation

The organisation plans and prepares for managing information security incidents by defining, establishing and communicating information security incident management processes, roles and responsibilities.

How we implement it

Our Incident Response Plan defines severities, roles, comms templates and external SLAs. Tabletop exercises run quarterly.

Owner: Head of Security Reviewed 11 April 2026
Implemented
A.5.25 Assessment and decision on information security events

The organisation assesses information security events and decides if they are to be categorised as information security incidents.

How we implement it

Events flow into a single triage queue with documented severity criteria. The on-call Security engineer triages within 15 minutes during business hours, 1 hour out of hours.

Owner: Head of Security Reviewed 11 April 2026
Implemented
A.5.26 Response to information security incidents

Information security incidents are responded to in accordance with the documented procedures.

How we implement it

Severity-1 incidents convene a bridge call within 15 minutes. We follow a Contain → Eradicate → Recover → Communicate workflow. Customer comms happen within 72 hours per UK GDPR Art. 33.

Owner: Head of Security Reviewed 11 April 2026
Implemented
A.5.27 Learning from information security incidents

Knowledge gained from information security incidents is used to strengthen and improve the information security controls.

How we implement it

Every Sev-1 and Sev-2 incident has a blameless post-incident review within 14 days. Action items are tracked to completion in the ISMS register.

Owner: Head of Security Reviewed 11 April 2026
Implemented
A.5.28 Collection of evidence

The organisation establishes and implements procedures for the identification, collection, acquisition and preservation of evidence related to information security events.

How we implement it

Audit logs are tamper-evident and retained for 1 year hot, 7 years cold. Forensic acquisition follows ACPO good-practice guidance.

Owner: Head of Security Reviewed 11 April 2026
Implemented
A.5.29 Information security during disruption

The organisation plans how to maintain information security at an appropriate level during disruption.

How we implement it

Our Business Continuity Plan defines security controls that must remain active during disruption (logging, access control, encryption). DR runbooks are tested quarterly.

Owner: Head of Security Reviewed 11 April 2026
Implemented
A.5.30 ICT readiness for business continuity

ICT readiness is planned, implemented, maintained and tested based on business continuity objectives and ICT continuity requirements.

How we implement it

Production runs across multiple Availability Zones with automated failover. RPO 1h, RTO 4h. Quarterly restore tests are documented in the ISMS.

Owner: Head of Security Reviewed 11 April 2026
Implemented
A.5.31 Legal, statutory, regulatory and contractual requirements

Legal, statutory, regulatory and contractual requirements relevant to information security and the organisation's approach to meet these requirements are identified, documented and kept up to date.

How we implement it

We maintain a compliance register covering UK GDPR, DPA 2018, PCI DSS, ICO guidance, and country-specific FA / sport governing-body requirements.

Owner: Head of Security Reviewed 11 April 2026
Implemented
A.5.32 Intellectual property rights

The organisation implements appropriate procedures to protect intellectual property rights.

How we implement it

Open-source dependencies are licence-scanned by SCA. Contributor agreements are required for OSS contributions. Customer-owned content remains the property of the customer.

Owner: Head of Security Reviewed 11 April 2026
Implemented
A.5.33 Protection of records

Records are protected from loss, destruction, falsification, unauthorised access and unauthorised release.

How we implement it

Financial and audit records are stored in WORM (write-once-read-many) storage with documented retention. Access is logged and limited to Finance and Audit roles.

Owner: Head of Security Reviewed 11 April 2026
Implemented
A.5.34 Privacy and protection of PII

The organisation identifies and meets the requirements regarding the preservation of privacy and protection of PII according to applicable laws and regulations and contractual requirements.

How we implement it

ISO/IEC 27018 governs how we handle PII in cloud environments. Our Privacy Notice and DPA describe controller and processor responsibilities.

Owner: Head of Security Reviewed 11 April 2026
Implemented
A.5.35 Independent review of information security

The organisation's approach to managing information security and its implementation is reviewed independently at planned intervals or when significant changes occur.

How we implement it

Independent review is performed annually by our external auditor (NQA). Internal audit performs interim reviews on a rolling 12-month cycle.

Owner: Head of Security Reviewed 11 April 2026
Implemented
A.5.36 Compliance with policies, rules and standards for information security

Compliance with the organisation's information security policy, topic-specific policies, rules and standards is regularly reviewed.

How we implement it

Automated compliance checks run continuously against our infrastructure. Manual policy adherence is audited at least annually.

Owner: Head of Security Reviewed 11 April 2026
Implemented
A.5.37 Documented operating procedures

Operating procedures for information processing facilities are documented and made available to personnel who need them.

How we implement it

Runbooks live in our internal docs system alongside the code. They are linked from monitoring alerts and reviewed when the underlying system changes.

Owner: Head of Security Reviewed 11 April 2026
Implemented

People

8 controls
A.6.1 Screening

Background verification checks on all candidates for employment are carried out prior to joining the organisation and on an ongoing basis taking into consideration applicable laws, regulations and ethics, and proportional to the business requirements, the classification of the information to be accessed and the perceived risks.

How we implement it

All new hires undergo right-to-work, identity, criminal-record (BS 7858 standard) and reference checks before access is provisioned. Higher-trust roles require enhanced DBS.

Owner: Head of Security Reviewed 11 April 2026
Implemented
A.6.2 Terms and conditions of employment

The employment contractual agreements state the personnel's and the organisation's responsibilities for information security.

How we implement it

Every contract includes confidentiality, IP assignment and obligations to comply with the Information Security Policy. Failure to comply is grounds for disciplinary action.

Owner: Head of Security Reviewed 11 April 2026
Implemented
A.6.3 Information security awareness, education and training

Personnel of the organisation and relevant interested parties receive appropriate information security awareness, education and training and regular updates of the organisation's information security policy, topic-specific policies and procedures, as relevant for their job function.

How we implement it

All staff complete onboarding security training within 7 days and annual refresher training. Engineers receive role-specific secure-coding training. Phishing simulations run monthly.

Owner: Head of Security Reviewed 11 April 2026
Implemented
A.6.4 Disciplinary process

A disciplinary process is formalised and communicated to take actions against personnel and other relevant interested parties who have committed an information security policy violation.

How we implement it

Security-related disciplinary actions follow the People team's documented procedure with HR and Legal review. Sanctions range from formal warning to termination and referral to law enforcement.

Owner: Head of Security Reviewed 11 April 2026
Implemented
A.6.5 Responsibilities after termination or change of employment

Information security responsibilities and duties that remain valid after termination or change of employment are defined, enforced and communicated to relevant personnel and other interested parties.

How we implement it

Exit briefings cover ongoing confidentiality, IP and non-solicit obligations. We retain audit-log evidence for 7 years post-departure.

Owner: Head of Security Reviewed 11 April 2026
Implemented
A.6.6 Confidentiality or non-disclosure agreements

Confidentiality or non-disclosure agreements reflecting the organisation's needs for the protection of information are identified, documented, regularly reviewed and signed by personnel and other relevant interested parties.

How we implement it

Mutual NDAs are signed before sharing any non-public security or product information with external parties. Internal NDAs are part of employment.

Owner: Head of Security Reviewed 11 April 2026
Implemented
A.6.7 Remote working

Security measures are implemented when personnel are working remotely to protect information accessed, processed or stored outside the organisation's premises.

How we implement it

Remote working baseline: managed device, full-disk encryption, MDM-enforced screen lock, VPN/Zero-Trust access, no public-Wi-Fi without VPN, secure home-office guidance.

Owner: Head of Security Reviewed 11 April 2026
Implemented
A.6.8 Information security event reporting

The organisation provides a mechanism for personnel to report observed or suspected information security events through appropriate channels in a timely manner.

How we implement it

All staff can report incidents via #security-incidents in Slack, security@teamfeepay.com, or an anonymous form. Reports are acknowledged within one business hour.

Owner: Head of Security Reviewed 11 April 2026
Implemented

Physical

14 controls
A.7.1 Physical security perimeters

Security perimeters are defined and used to protect areas that contain information and other associated assets.

How we implement it

We operate a cloud-hosted service — production data centres are AWS regions in the UK and EU, with documented physical security audited under ISO 27001 and SOC 2.

Owner: Head of Security Reviewed 11 April 2026
Implemented
A.7.2 Physical entry

Secure areas are protected by appropriate entry controls and access points.

How we implement it

Office access requires badge + photo ID. Visitors are escorted and logged. The AWS facilities we rely on use multi-factor physical access controls.

Owner: Head of Security Reviewed 11 April 2026
Implemented
A.7.3 Securing offices, rooms and facilities

Physical security for offices, rooms and facilities is designed and implemented.

How we implement it

Sensitive meetings happen in dedicated rooms with no recording. Server rooms (where they exist) require a separate badge group.

Owner: Head of Security Reviewed 11 April 2026
Implemented
A.7.4 Physical security monitoring

Premises are continuously monitored for unauthorised physical access.

How we implement it

Our offices have CCTV at all entry points with 30-day retention. Out-of-hours access is alerted to Security on-call.

Owner: Head of Security Reviewed 11 April 2026
Implemented
A.7.5 Protecting against physical and environmental threats

Protection against physical and environmental threats, such as natural disasters and other intentional or unintentional physical threats to infrastructure, is designed and implemented.

How we implement it

Our DR strategy uses two physically separate cloud regions. Production data has no single-site dependency.

Owner: Head of Security Reviewed 11 April 2026
Implemented
A.7.6 Working in secure areas

Security measures for working in secure areas are designed and implemented.

How we implement it

Secure-area working procedures cover clean desks, restricted devices and visitor escorting.

Owner: Head of Security Reviewed 11 April 2026
Implemented
A.7.7 Clear desk and clear screen

Clear desk rules for papers and removable storage media and clear screen rules for information processing facilities are defined and appropriately enforced.

How we implement it

Devices auto-lock within 5 minutes of inactivity (enforced by MDM). Confidential paper output is shredded; we maintain a clear-desk policy.

Owner: Head of Security Reviewed 11 April 2026
Implemented
A.7.8 Equipment siting and protection

Equipment is sited securely and protected.

How we implement it

Workstations are not visible from public-facing windows. Removable media is prohibited on production endpoints.

Owner: Head of Security Reviewed 11 April 2026
Implemented
A.7.9 Security of assets off-premises

Off-site assets are protected.

How we implement it

Off-site equipment (laptops, phones) is enrolled in MDM, encrypted at rest, with remote wipe capability.

Owner: Head of Security Reviewed 11 April 2026
Implemented
A.7.10 Storage media

Storage media is managed through its life cycle of acquisition, use, transportation and disposal in accordance with the organisation's classification scheme and handling requirements.

How we implement it

Removable media is banned on managed endpoints. Cloud-backed encrypted storage replaces all USB use cases.

Owner: Head of Security Reviewed 11 April 2026
Implemented
A.7.11 Supporting utilities

Information processing facilities are protected from power failures and other disruptions caused by failures in supporting utilities.

How we implement it

We rely on AWS facilities with N+1 power, multiple ISPs and standby generators. Our offices have UPS-protected network closets.

Owner: Head of Security Reviewed 11 April 2026
Implemented
A.7.12 Cabling security

Cables carrying power, data or supporting information services are protected from interception, interference or damage.

How we implement it

Office cabling is routed through protected containment. Inter-site connectivity uses encrypted tunnels regardless of carrier.

Owner: Head of Security Reviewed 11 April 2026
Implemented
A.7.13 Equipment maintenance

Equipment is maintained correctly to ensure availability, integrity and confidentiality of information.

How we implement it

Endpoint maintenance is delivered through MDM. Cloud infrastructure maintenance is performed by our cloud provider under SLA.

Owner: Head of Security Reviewed 11 April 2026
Implemented
A.7.14 Secure disposal or re-use of equipment

Items of equipment containing storage media are verified to ensure that any sensitive data and licensed software has been removed or securely overwritten prior to disposal or re-use.

How we implement it

Endpoints are wiped to NIST SP 800-88 standards before reissue or disposal. Cloud-managed storage is cryptographically erased on decommission.

Owner: Head of Security Reviewed 11 April 2026
Implemented

Technological

34 controls
A.8.1 User endpoint devices

Information stored on, processed by or accessible via user endpoint devices is protected.

How we implement it

All endpoints are MDM-managed, full-disk-encrypted (FileVault/BitLocker), with EDR, screen-lock and remote-wipe enforced.

Owner: Head of Security Reviewed 11 April 2026
Implemented
A.8.2 Privileged access rights

The allocation and use of privileged access rights is restricted and managed.

How we implement it

Privileged access is JIT — engineers request elevated access through an approval workflow; access is time-bound and logged.

Owner: Head of Security Reviewed 11 April 2026
Implemented
A.8.3 Information access restriction

Access to information and other associated assets is restricted in accordance with the established topic-specific policy on access control.

How we implement it

Application-level access is enforced by RBAC and ABAC. Database access to customer data is restricted to a small named group and logged.

Owner: Head of Security Reviewed 11 April 2026
Implemented
A.8.4 Access to source code

Read and write access to source code, development tools and software libraries is appropriately managed.

How we implement it

Source code lives in a managed Git provider. Production-deploying repos require branch protection, code review and signed commits.

Owner: Head of Security Reviewed 11 April 2026
Implemented
A.8.5 Secure authentication

Secure authentication technologies and procedures are implemented based on information access restrictions and the topic-specific policy on access control.

How we implement it

Workforce authentication is SSO via Azure AD with phishing-resistant MFA. Customer-facing authentication supports MFA and (for Business plans) SAML/OIDC SSO.

Owner: Head of Security Reviewed 11 April 2026
Implemented
A.8.6 Capacity management

The use of resources is monitored and adjusted in line with current and expected capacity requirements.

How we implement it

Capacity is tracked per service with alerts at 70% and 85%. Autoscaling handles transient load; quarterly capacity planning handles trend growth.

Owner: Head of Security Reviewed 11 April 2026
Implemented
A.8.7 Protection against malware

Protection against malware is implemented and supported by appropriate user awareness.

How we implement it

Managed EDR runs on every endpoint and inbound email scans for malware. Production hosts are immutable and rebuilt rather than patched in place.

Owner: Head of Security Reviewed 11 April 2026
Implemented
A.8.8 Management of technical vulnerabilities

Information about technical vulnerabilities of information systems in use is obtained, the organisation's exposure to such vulnerabilities is evaluated and appropriate measures are taken.

How we implement it

Critical CVEs are patched within 7 days, high within 30, others on a rolling cadence. SCA and SAST run on every build; DAST runs nightly against staging.

Owner: Head of Security Reviewed 11 April 2026
Implemented
A.8.9 Configuration management

Configurations, including security configurations, of hardware, software, services and networks are established, documented, implemented, monitored and reviewed.

How we implement it

Production configuration is declared in Terraform and Kubernetes manifests with drift detection. Endpoints are baselined to CIS Level 1 via MDM.

Owner: Head of Security Reviewed 11 April 2026
Implemented
A.8.10 Information deletion

Information stored in information systems, devices or any other storage media is deleted when no longer required.

How we implement it

Customer accounts are deleted 30 days after cancellation. Backups are purged on a 90-day rolling window. Deletion is logged and verifiable.

Owner: Head of Security Reviewed 11 April 2026
Implemented
A.8.11 Data masking

Data masking is used in accordance with the organisation's topic-specific policy on access control and other related topic-specific policies, and business requirements, taking applicable legislation into consideration.

How we implement it

Non-production environments are seeded with anonymised data. Where production data is required for support, just-in-time access is logged and time-boxed.

Owner: Head of Security Reviewed 11 April 2026
Implemented
A.8.12 Data leakage prevention

Data leakage prevention measures are applied to systems, networks and any other devices that process, store or transmit sensitive information.

How we implement it

DLP rules monitor email and SaaS for sensitive data egress. Endpoint controls prevent removable-media writes. Cloud storage is bucket-level locked-down.

Owner: Head of Security Reviewed 11 April 2026
Implemented
A.8.13 Information backup

Backup copies of information, software and systems are maintained and regularly tested in accordance with the agreed topic-specific policy on backup.

How we implement it

Production data has continuous point-in-time backup for 14 days and daily snapshots retained for 35 days. Restore tests run quarterly.

Owner: Head of Security Reviewed 11 April 2026
Implemented
A.8.14 Redundancy of information processing facilities

Information processing facilities are implemented with redundancy sufficient to meet availability requirements.

How we implement it

Multi-AZ deployment for stateful workloads; multi-region failover for the control plane. Targets: RPO 1h, RTO 4h.

Owner: Head of Security Reviewed 11 April 2026
Implemented
A.8.15 Logging

Logs that record activities, exceptions, faults and other relevant events are produced, stored, protected and analysed.

How we implement it

Application, system and network logs ship to a central SIEM with tamper-evident storage. Retention is 1 year hot, 7 years cold.

Owner: Head of Security Reviewed 11 April 2026
Implemented
A.8.16 Monitoring activities

Networks, systems and applications are monitored for anomalous behaviour and appropriate actions taken to evaluate potential information security incidents.

How we implement it

Detection rules run continuously in the SIEM and EDR. Alerts page the on-call Security engineer 24/7 with documented response SLAs.

Owner: Head of Security Reviewed 11 April 2026
Implemented
A.8.17 Clock synchronisation

The clocks of information processing systems used by the organisation are synchronised to approved time sources.

How we implement it

All systems sync to time.aws.com and time.cloudflare.com via NTP. Drift is alerted at 1 second.

Owner: Head of Security Reviewed 11 April 2026
Implemented
A.8.18 Use of privileged utility programs

The use of utility programs that can be capable of overriding system and application controls is restricted and tightly controlled.

How we implement it

Privileged utilities (database shells, deploy scripts) require JIT access, two-person approval for destructive commands and immutable session logs.

Owner: Head of Security Reviewed 11 April 2026
Implemented
A.8.19 Installation of software on operational systems

Procedures and measures are implemented to securely manage software installation on operational systems.

How we implement it

Production hosts are immutable; software changes flow through CI/CD with code review and automated tests. Endpoint software is managed via MDM allow-listing.

Owner: Head of Security Reviewed 11 April 2026
Implemented
A.8.20 Networks security

Networks and network devices are secured, managed and controlled to protect information in systems and applications.

How we implement it

Production networks default-deny. Ingress flows through a WAF and DDoS scrubber. East-west traffic is mTLS where supported.

Owner: Head of Security Reviewed 11 April 2026
Implemented
A.8.21 Security of network services

Security mechanisms, service levels and service requirements of network services are identified, implemented and monitored.

How we implement it

Network services are sourced from tier-1 providers under documented SLAs. Security characteristics are reviewed at supplier onboarding and annually.

Owner: Head of Security Reviewed 11 April 2026
Implemented
A.8.22 Segregation of networks

Groups of information services, users and information systems are segregated in the organisation's networks.

How we implement it

Production, staging and corporate networks are fully segregated. Workloads are segmented by service with explicit allow-lists.

Owner: Head of Security Reviewed 11 April 2026
Implemented
A.8.23 Web filtering

Access to external websites is managed to reduce exposure to malicious content.

How we implement it

Endpoint DNS is filtered through a managed secure DNS provider. Categories like malware, phishing and high-risk are blocked by default.

Owner: Head of Security Reviewed 11 April 2026
Implemented
A.8.24 Use of cryptography

Rules for the effective use of cryptography, including cryptographic key management, are defined and implemented.

How we implement it

TLS 1.2+ in transit; AES-256 at rest. Keys are held in a managed KMS with annual rotation and dual-control for backup keys.

Owner: Head of Security Reviewed 11 April 2026
Implemented
A.8.25 Secure development life cycle

Rules for the secure development of software and systems are established and applied.

How we implement it

We follow a documented SDLC aligned to OWASP SAMM Level 2 — threat modelling on new designs, code review, SAST/SCA, DAST, and dependency policy gates.

Owner: Head of Security Reviewed 11 April 2026
Implemented
A.8.26 Application security requirements

Information security requirements are identified, specified and approved when developing or acquiring applications.

How we implement it

Every product epic begins with documented security requirements derived from the threat model, OWASP ASVS and PCI DSS where applicable.

Owner: Head of Security Reviewed 11 April 2026
Implemented
A.8.27 Secure system architecture and engineering principles

Principles for engineering secure systems are established, documented, maintained and applied to any information system development activities.

How we implement it

Engineering follows documented principles: zero-trust, defence in depth, secure by default, fail closed, minimise blast radius, and explicit identity for every actor.

Owner: Head of Security Reviewed 11 April 2026
Implemented
A.8.28 Secure coding

Secure coding principles are applied to software development.

How we implement it

Coding standards mandate parameterised queries, output encoding, dependency pinning, secrets via the vault, and review for any custom crypto.

Owner: Head of Security Reviewed 11 April 2026
Implemented
A.8.29 Security testing in development and acceptance

Security testing processes are defined and implemented in the development life cycle.

How we implement it

SAST and SCA run on every PR. DAST runs nightly against staging. Penetration testing runs annually plus on significant change.

Owner: Head of Security Reviewed 11 April 2026
Implemented
A.8.30 Outsourced development

The organisation directs, monitors and reviews the activities related to outsourced system development.

How we implement it

Outsourced development goes through the same SDLC gates and code review as internal work. Outsourcers sign confidentiality and IP-assignment agreements.

Owner: Head of Security Reviewed 11 April 2026
Implemented
A.8.31 Separation of development, test and production environments

Development, testing and production environments are separated and secured.

How we implement it

Production has its own cloud account, identity boundary and network. Customer data does not flow into non-production environments.

Owner: Head of Security Reviewed 11 April 2026
Implemented
A.8.32 Change management

Changes to information processing facilities and information systems are subject to change management procedures.

How we implement it

All production changes go through pull-request review, automated tests and a documented deployment workflow. Emergency changes have a post-deploy review.

Owner: Head of Security Reviewed 11 April 2026
Implemented
A.8.33 Test information

Test information is appropriately selected, protected and managed.

How we implement it

Non-production environments use synthetic or anonymised data. Where real data is necessary, it is masked and access is logged.

Owner: Head of Security Reviewed 11 April 2026
Implemented
A.8.34 Protection of information systems during audit testing

Audit tests and other assurance activities involving assessment of operational systems are planned and agreed between the tester and appropriate management.

How we implement it

Audit and assessment activities are pre-agreed, scoped and use read-only access by default. Any destructive testing happens in dedicated environments.

Owner: Head of Security Reviewed 11 April 2026
Implemented

ISO/IEC 27018:2019 — PII protection in public clouds

Processor-specific control extensions and the eleven Annex A PII protection principles.

ISO/IEC 27018:2019
Control matrix

PII / Cloud processor extensions

8 controls
27018-9 Access control for PII

Access to PII is restricted to authorised personnel, individually attributable, and reviewed at intervals appropriate to the sensitivity of the data.

How we implement it

Access to customer PII requires JIT elevation through an approved workflow; no shared accounts touch PII; access is reviewed quarterly.

Owner: DPO Reviewed 11 April 2026
Implemented
27018-10 Cryptography of PII

PII transmitted over public networks is protected by cryptography. Keys used to protect PII are managed under documented procedures.

How we implement it

All customer PII in transit uses TLS 1.2+; at rest uses AES-256 with keys held in a managed KMS with documented rotation and access logging.

Owner: DPO Reviewed 11 April 2026
Implemented
27018-11 Physical and environmental security for PII

Physical access to facilities processing PII is restricted to authorised personnel and is audited.

How we implement it

Production PII is processed only in tier-1 cloud facilities (UK/EU regions) whose physical controls are independently audited under ISO 27001 / SOC 2.

Owner: DPO Reviewed 11 April 2026
Implemented
27018-12 Operations security and PII

Logs of activities affecting PII are maintained, protected and reviewable on request.

How we implement it

All access to customer PII generates an audit event captured by our SIEM. Logs are tamper-evident and retained for at least 1 year.

Owner: DPO Reviewed 11 April 2026
Implemented
27018-13 Communications security for PII

Transfers of PII between systems and to PII controllers are encrypted and authenticated.

How we implement it

PII transfers to or from customers occur via authenticated, encrypted APIs. PII is never transferred to a third party except an approved sub-processor under DPA.

Owner: DPO Reviewed 11 April 2026
Implemented
27018-15 Supplier relationships involving PII

Sub-processors that process PII are bound by equivalent or stricter PII-protection obligations and are disclosed to the PII controller.

How we implement it

Sub-processors are listed on this Trust Centre. New or replaced sub-processors are announced with 30 days notice to allow controllers to object.

Owner: DPO Reviewed 11 April 2026
Implemented
27018-16 Incident management involving PII

Incidents affecting PII are reported to the PII controller within agreed timescales and include sufficient information for the controller to fulfil its own obligations.

How we implement it

Confirmed PII incidents are reported to affected customers within 72 hours, in line with UK GDPR Article 33, with the information required for them to notify their data subjects.

Owner: DPO Reviewed 11 April 2026
Implemented
27018-18 Compliance and PII

The processor identifies the legal and regulatory obligations applicable to PII it processes and demonstrates compliance.

How we implement it

We maintain a compliance register covering UK GDPR, DPA 2018, ICO codes of practice, and customer DPAs. Compliance is reviewed annually and on regulatory change.

Owner: DPO Reviewed 11 April 2026
Implemented

PII protection principles

11 controls
27018-A.1 Consent and choice

The PII processor processes PII only on documented instructions from the PII controller; the processor does not use PII for any other purpose without controller authorisation.

How we implement it

We act on documented controller instructions only. We do not use customer PII for marketing, profiling, training models or any purpose outside the contracted service.

Owner: DPO Reviewed 11 April 2026
Implemented
27018-A.2 Purpose legitimacy and specification

PII is processed only for the purposes specified by the PII controller.

How we implement it

Our DPA enumerates the purposes for which we process PII. Any new purpose requires written controller instruction.

Owner: DPO Reviewed 11 April 2026
Implemented
27018-A.3 Collection limitation

The processor does not collect PII beyond what is necessary for the processing instructed by the controller.

How we implement it

We collect only what the customer's use of the platform requires. Optional fields are clearly marked as optional in the product and the API.

Owner: DPO Reviewed 11 April 2026
Implemented
27018-A.4 Data minimisation

Temporary files and outputs that include PII are minimised and the PII is erased as soon as it is no longer needed.

How we implement it

Temporary files containing PII are written to ephemeral, encrypted volumes and erased on job completion. Diagnostic dumps are scrubbed of PII.

Owner: DPO Reviewed 11 April 2026
Implemented
27018-A.5 Use, retention and disclosure limitation

PII is retained no longer than necessary for the agreed purpose and is not disclosed except as instructed by the controller or required by law.

How we implement it

Retention defaults are documented per data type and overrideable by the controller. Disclosure to authorities is permitted only with legal compulsion and, where lawful, with prior notice to the controller.

Owner: DPO Reviewed 11 April 2026
Implemented
27018-A.6 Accuracy and quality

Tools exist for the controller to keep PII accurate, complete and up to date.

How we implement it

Admin tooling lets controllers (club administrators) correct PII directly. API endpoints provide the same capability programmatically.

Owner: DPO Reviewed 11 April 2026
Implemented
27018-A.7 Openness, transparency and notice

The processor provides clear information about its PII handling practices, including sub-processors.

How we implement it

This Trust Centre and our DPA describe how we handle PII, the sub-processors we use, the regions in which we process, and our retention defaults.

Owner: DPO Reviewed 11 April 2026
Implemented
27018-A.8 Individual participation and access

The processor supports the controller in fulfilling data subject rights, including access, correction and erasure.

How we implement it

Controllers can fulfil access, correction and erasure requests directly via the admin console. Where they need our help, we respond within 30 days of a written request.

Owner: DPO Reviewed 11 April 2026
Implemented
27018-A.9 Accountability

The processor demonstrates accountability for its PII obligations through evidence, audits and breach notification.

How we implement it

Accountability is demonstrated through ISO/IEC 27001 + 27018 certification, independent pen-testing, audit logs, and our published incident-response SLAs.

Owner: DPO Reviewed 11 April 2026
Implemented
27018-A.10 Information security

The processor implements appropriate technical and organisational measures to protect PII against unauthorised access, alteration, disclosure or destruction.

How we implement it

Our ISO 27001-aligned ISMS, encryption-in-transit-and-at-rest, key management, JIT access, EDR, SIEM monitoring and quarterly DR testing all serve this control.

Owner: DPO Reviewed 11 April 2026
Implemented
27018-A.11 Privacy compliance

The processor demonstrates compliance with applicable PII protection legislation and regulation in the jurisdictions where PII is processed.

How we implement it

PII is processed only in UK and EU regions. Where transfers occur outside the UK/EEA, we rely on UK and EU SCCs and supplementary measures, documented per transfer.

Owner: DPO Reviewed 11 April 2026
Implemented