Applicants should maintain technical and security controls appropriate to the size, architecture, product scope, outsourcing model, and risk profile of their operations.
Technical and security controls are intended to support system integrity, service continuity, access protection, change discipline, monitoring, and incident response across the operating environment.
Applicants should be able to demonstrate not only what controls exist on paper, but how those controls function in practice across infrastructure, platforms, administrative access, releases, and operational oversight.
Applicants should be able to explain their technical environment in a structured and understandable way. This includes production environments, administrative components, key integrations, critical dependencies, and any significant third-party systems.
Where the platform relies on external providers, cloud services, aggregators, or specialised infrastructure vendors, applicants should clearly identify those dependencies and explain how operational accountability is maintained.
Access to administrative tools, infrastructure, dashboards, databases, and operational back-office functions should be restricted according to role and business need.
Applicants should be able to show how access is granted, reviewed, changed, and removed. Privileged access should receive particular control attention, especially where technical administrators, developers, or third-party vendors can affect production systems or sensitive data.
Appropriate logging and monitoring should exist across systems relevant to security, operations, and accountability. Logs should support the detection of unusual administrative behaviour, system changes, access events, errors, and other material activity.
Monitoring should not stop at data collection. Applicants should also explain how alerts are reviewed, who reviews them, what thresholds apply, and how incidents or anomalies are escalated.
Define which systems, events, and actions generate logs.
Identify which alerts or conditions are actively reviewed.
Set out how suspicious events, technical failures, or access anomalies are routed for response.
Maintain logs and related records in a way that supports auditability and follow-up review.
Applicants should maintain backup and recovery arrangements appropriate to the criticality of their systems and data. This includes understanding what is backed up, how frequently backups occur, how restoration is tested, and who is responsible for recovery decision-making.
Business continuity should not exist as a vague statement. Applicants should be able to explain practical resilience arrangements and recovery pathways for core services.
Technical changes should be governed through a defined process. Applicants should be able to explain how changes are requested, reviewed, approved, tested, deployed, and rolled back where necessary.
This is especially important for suppliers, but it also matters for operator environments where platform settings, payment flows, risk rules, or administrative tooling can be altered.
Applicants should maintain an incident response process that identifies how technical or security incidents are detected, classified, escalated, investigated, and recorded.
The process should identify who owns incident handling, how communication occurs internally, and how material incidents are preserved in an internal record or register.
A technical and security framework should be supported by tangible evidence. Useful evidence may include:
Saying that a platform is secure is meaningless without actual control logic, documented ownership, monitoring evidence, and a clear explanation of how technical risks are managed in practice.
