Premier League moves the goalposts as cyber rulebook introduces 22 security control areas

Share

Cyber security is now written into the Premier League rulebook

The Premier League has made cyber security a matter of club compliance, not simply IT good practice.

Under Rule J.9 and Appendix 11 of the Premier League Handbook 2026/27, every Premier League club must implement and maintain a phased set of Information Security Baselines. The framework covers 22 control areas and reaches far beyond passwords and patching. It brings board oversight, player and supporter data, stadium technology, suppliers, incident response, recovery evidence and independent audit into one formal programme.

That is the important change. A club will not only need security controls. It will need to show the League that those controls are implemented, maintained and supported by evidence.

The rule in four dates

Requirement	Deadline	What the club must do
Annual interim assessment	10 January each season	Assess compliance with every applicable baseline
Remediation plan	Within 28 days of a non-compliant interim assessment	Explain the steps the club will take to achieve compliance
Phase One	30 April 2027	Implement and maintain the first group of requirements
Phase Two	30 April 2028	Implement and maintain the second group of requirements
Phase Three	30 April 2029	Implement and maintain the remaining requirements
Annual final assessment	30 April each season	Submit a final assessment with supporting evidence

The wording “implement and maintain” matters. These are not one-off project dates. Once a requirement becomes applicable, the club must continue operating it.

Rule J.11 also allows the League to request further information or evidence while monitoring progress. Rule J.13 permits dispensation in exceptional circumstances, but only at the League's discretion and potentially subject to conditions. Promoted clubs are also brought into the timetable under Rule J.14.

Why this matters beyond the IT department

Modern football clubs are complex, data-dependent organisations. Their systems hold or control:

• player contracts, transfer documents and scouting intelligence;
• medical, biometric, performance and safeguarding records;
• supporter identities, ticketing accounts and payment information;
• payroll, employment, legal and board records;
• sponsorship, broadcast and commercial agreements;
• stadium access, CCTV, building, communications and operational technology;
• supplier connections, cloud services and proprietary analytics.

A serious incident can therefore move quickly from an IT problem to a football, commercial, legal, safety or matchday problem. Appendix 11 reflects that reality. It requires clubs to understand which systems and data are genuinely critical, who can reach them, which suppliers they depend on and how the club would continue operating if connected systems became unavailable.

The Premier League's timing also reflects the scale of the industry. Deloitte reported aggregate Premier League club revenue of £6.8 billion for 2024/25, an 8% increase on the previous season. Revenue does not itself measure cyber risk, but it illustrates the commercial scale, valuable information and extensive technology now sitting behind the competition.

The biggest change is the evidence requirement

Rule J.10 requires an interim compliance assessment by 10 January each season. If a club is not fully compliant, it must provide a detailed remediation plan within 28 days. Rule J.12 then requires a final assessment, with supporting evidence, by 30 April.

That turns Appendix 11 into an assurance programme. A policy document alone will not prove that a control operates. Clubs will need an evidence trail capable of showing, for example:

• when critical data was classified and by whom;
• that privileged access is approved and reviewed;
• that network segmentation exists in practice;
• that security alerts are monitored and acted upon;
• that immutable backups are maintained;
• that restoration has actually been tested;
• that suppliers have been risk assessed;
• that incident exercises and independent assessments took place;
• that weaknesses have owners, deadlines and recorded remediation.

For boards and executive teams, this changes the governing question from “Do we have a cyber policy?” to “What evidence would we submit today?”

Twenty-two control areas, not twenty-two individual controls

Appendix 11 is sometimes described as introducing 22 controls. That understates its size. It contains 22 control areas, each with several individual requirements distributed across three phases.

Leadership and assurance	Technology and data	Resilience and ecosystem
Risk, governance and policies	Access, assets, networks and endpoints	Backups and incident response
Personnel security and training	Anti-malware, email and vulnerability management	Cyber insurance and supplier risk
Accreditation and audit	Retention, classification, IoT and monitoring	Recovery, assurance and continuity

The result is closer to a club-wide cyber operating model than a short compliance checklist.

Clubs must identify what matters most

The framework repeatedly distinguishes critical systems and critical data from the rest of the estate. Clubs must maintain hardware and software inventories, classify assets by impact, map data flows and maintain an inventory of systems requiring security assurance.

That work should answer a practical question: what information or system could the club not afford to lose, expose or leave unavailable?

For one club the priority may be player medical records and transfer documentation. For another it may include supporter identity data, ticketing systems, payroll, broadcast operations, commercial negotiations, stadium access or clean recovery data. The answer will not come from storage volume alone. It depends on confidentiality, operational impact, legal duties, replacement difficulty and the consequences of compromise.

Until that critical set is defined, backup scope, recovery objectives, access controls and supplier assurance cannot be designed properly.

Backup is only credible when recovery is proved

Control area 15 requires clubs to document the scope and schedule for critical-data backups, maintain immutable backups, follow the NCSC 3-2-1 principle, agree Recovery Time Objectives and Recovery Point Objectives with business owners, and conduct at least annual full or partial restoration tests.

The distinction is important:

• a backup is a copy;
• immutability is designed to prevent that copy being altered or deleted;
• a restoration test proves whether the copy can be used;
• disconnection removes the standing network path an attacker would otherwise use.

Appendix 11 requires immutable backups and points clubs to the NCSC 3-2-1 principle. It does not prescribe Offline Secure Storage®. However, NCSC ransomware-resistant backup guidance stresses the importance of keeping backups separate from live systems and preventing attackers from reaching them. For a club's most consequential records, the board should therefore ask whether one protected copy should be physically disconnected rather than merely protected by another connected control plane.

That is not a substitute for backup. It is a separate resilience decision about which data should remain beyond an attacker's network reach.

Stadium and operational technology are in scope

Appendix 11 expressly addresses Internet of Things devices. Clubs must inventory and harden them, manage credentials, encrypt data, segregate devices on the network, monitor them and plan for failure. The Handbook specifically gives stadium access control as an example where a manual fallback may be necessary.

This is one of the framework's most important details. Stadium access, CCTV, building management, communications, broadcast systems and connected sensors can bridge the digital and physical operation of a club. Their failure can affect people and matchday operations, not only data.

For security leaders, the task is therefore not simply to draw a corporate network diagram. It is to identify connections between office IT, cloud platforms, third parties, stadium systems and operational technology, then decide where access should be restricted, segmented or capable of rapid physical disconnection.

Suppliers are part of the club's risk

Ticketing, payments, medical platforms, analytics, communications, stadium systems and commercial services often depend on third parties. Appendix 11 requires formal supplier-risk governance, business-impact assessment, proportionate security assessment, contractual requirements and ongoing monitoring of key suppliers.

It also anticipates remediation plans and, where appropriate, joint incident-response or business-continuity exercises.

This means a questionnaire sent at onboarding will not be enough for every supplier. Clubs need to know which providers can access critical data or operations, what happens if those providers fail, how quickly access can be revoked and whether evidence required by the League remains available across the supply chain.

Incident response must reach containment and recovery

Appendix 11 assumes prevention can fail. Clubs must maintain an incident-response and recovery plan, define roles, triage incidents, prepare playbooks, understand external escalation routes, exercise at least annually and feed lessons back into the programme.

The practical test is whether a club can move quickly through four distinct stages:

1. Detect: recognise abnormal or malicious activity.
2. Decide: identify the affected systems, authority and required action.
3. Contain: isolate the relevant account, supplier connection, network path or operational zone.
4. Recover: restore trusted data and services in the correct order.

A plan that ends at notification is incomplete. The response must connect to disaster recovery and business continuity, with technical actions rehearsed before an incident.

Logs and evidence must survive the incident

Protective monitoring is one of the largest control areas in Appendix 11. Clubs must centralise relevant logging, protect logs in transit and at rest, maintain an immutable repository, synchronise time, establish behavioural baselines and test detection processes.

That creates a second evidence problem. The same attack being investigated may attempt to alter or destroy the records needed to reconstruct it. Log architecture must therefore be designed for both detection and post-incident integrity.

This evidence may matter to the League, insurers, auditors, legal advisers and regulators. It must be reliable, retained appropriately and accessible when production systems are under pressure.

Independent scrutiny makes this an ongoing programme

Clubs must select an appropriate recognised security framework, obtain executive approval and validate control effectiveness through third-party assessment. Appendix 11 also requires a third-party audit plan for independent security assessments each season and a formal three-year Information Security Strategy.

This prevents the programme becoming a rush towards a single deadline. Clubs need governance that can maintain controls, preserve evidence and fund improvement over several seasons.

The £100,000 figure is not the whole exposure

Rule W.12 gives the Premier League Board a general power to impose a fine of up to £100,000 when dealing summarily with a breach of the Rules. That figure has attracted attention, but it should not be treated as the maximum consequence of a cyber incident.

Where personal data is involved, the Information Commissioner's Office may investigate under UK data protection law. Under the ICO statutory penalty framework, the UK GDPR higher statutory maximum is the greater of £17.5 million or 4% of worldwide annual turnover. These are legal ceilings, not automatic fines, and the relevant undertaking and circumstances would have to be determined in each case.

The following figures simply illustrate what 4% of reported club revenue would look like. They are not predictions of a penalty.

Club	Reported revenue, year to May 2025	Illustrative 4% figure
Liverpool	£703.0 million	£28.1 million
Manchester City	£694.1 million	£27.8 million
Manchester United	£666.5 million	£26.7 million
Tottenham Hotspur	£565.3 million	£22.6 million

The wider exposure may also include operational interruption, recovery costs, contractual claims, regulatory action, compromised player or supporter information, lost commercial advantage and reputational damage. The Premier League's own disciplinary power is only one part of that picture.

What club leaders should do now

The first implementation deadline is 30 April 2027, but the annual evidence cycle makes waiting risky. A sensible starting sequence is:

1. Name an executive owner. Establish who is accountable for the programme and evidence submission.
2. Map every Appendix 11 requirement by phase. Record the control owner, present state, evidence, gap, budget and delivery date.
3. Define critical systems and data. Include football, medical, commercial, supporter, corporate and stadium operations.
4. Map dependencies and routes. Document suppliers, privileged access, data flows and connections between business and stadium technology.
5. Test containment and recovery. Exercise a realistic ransomware or supplier-compromise scenario and restore selected critical data.
6. Protect the evidence. Make sure logs, recovery data, decisions and audit records can survive the incident they are intended to explain.
7. Commission independent challenge early. Do not wait until the final assessment to discover that a control cannot be evidenced.

The most useful board question is not “Are we compliant?” It is: which requirement could we not prove today, and what would happen if that control failed during a match week?

A plain-English guide to all 22 areas

The summary below follows the numbering in Appendix 11. Clubs should use the official Handbook to confirm the exact wording and phase assigned to each individual requirement.

1. Risk: document the risk policy and method, define appetite, assess threats and new technology, measure control maturity and manage exceptions.
2. Governance: establish ownership, objectives, stakeholders, reporting, escalation and documented critical security services.
3. Policies: maintain executive-approved security policies and review them as threats and obligations change.
4. Personnel security: vet staff, identify high-risk roles, train users and specialists, exercise executives and monitor insider risk.
5. Access and authentication: govern accounts throughout their lifecycle, use strong authentication and MFA, control privilege and review access.
6. Assets: maintain accurate inventories, approved configurations, impact classifications and secure disposal processes.
7. Network and internet: keep network maps current, segment systems, remove unsafe defaults, restrict access and monitor network activity.
8. Endpoint hardening: encrypt and harden devices, restrict removable media and administration, deploy EDR and maintain approved configurations.
9. Anti-malware: protect supported systems, monitor alerts, prevent tampering and define compensating controls for unsupported technology.
10. Email: implement SPF, DKIM and DMARC, filter threats, monitor gateways, train users and remove malicious messages retrospectively where possible.
11. Patching and vulnerabilities: identify, assess and remediate vulnerabilities, scan routinely and manage disclosure and accepted risk.
12. Data retention: document retention periods, train users and account for legal and contractual obligations.
13. Data classification and loss prevention: label information, encrypt sensitive data, control access and transfers, map flows and dispose of data securely.
14. Internet of Things: inventory, harden, segregate, monitor and patch connected devices, with fallback plans for operational failure.
15. Backups: define scope and frequency, maintain immutable copies, follow NCSC 3-2-1, agree recovery objectives and test restoration.
16. Assurance: identify critical systems, test them appropriately, remediate findings and validate control effectiveness.
17. Incident response: maintain and exercise plans covering triage, responsibilities, escalation, recovery, insurance and lessons learned.
18. Cyber insurance: assess available cover, document it and integrate insurer contacts and requirements into response plans.
19. Third-party and vendor risk: assess supplier impact, set contractual controls, monitor key providers and plan joint response where needed.
20. Accreditation: select an appropriate recognised framework, obtain executive approval and validate it through regular third-party audits.
21. Protective monitoring: centralise and protect logs, build detection baselines, tune alerts, measure performance and test the process.
22. Audit: plan internal and independent assessment and maintain a three-year Information Security Strategy.

Primary source: Premier League Handbook 2026/27, Rules J.9 to J.14 and Appendix 11. Revenue figures are drawn from Deloitte's Annual Review of Football Finance and published club accounts. UK GDPR maximum-penalty figures are from ICO statutory guidance.

Firevault's view: decide what an attacker must never reach

Appendix 11 is technology-neutral. It does not certify products and it does not require Offline Secure Storage®. Its value is that it forces clubs to connect governance, critical-data identification, containment, evidence and recovery.

Firevault's view is that a club should identify the small, consequential set of records that must remain intact even if connected identity, cloud, backup or supplier systems are compromised. That may include selected player and medical records, contracts, board material, commercial agreements, forensic evidence and trusted recovery data.

Those records can then be considered for a physically disconnected storage layer, alongside rather than instead of the club's backup and recovery programme.

Read our Offline Secure Storage guide for football clubs or explore the Control Blueprint to Contain Active Breaches.

How Firevault would handle this

A recovery copy an attacker cannot reach

Offline Secure Storage® keeps a clean copy of your data on hardware that is physically disconnected, so backup and recovery do not depend on systems an intruder can touch.