Data protection obligations do not apply uniformly across all industries. When your business operates in telecommunications, financial services or technology, UK GDPR compliance becomes only one layer of your regulatory obligations. Telecoms providers face PECR traffic and location data duties and Telecommunications (Security) Act 2021 security overlays. Payment services firms navigate FCA authentication rules, PSR open banking data sharing requirements and Consumer Duty expectations around how they handle customer information. SaaS platforms must allocate processor and controller roles correctly in complex cloud architectures and manage international transfer risks through Product design itself. Sector-specific data protection is the intersection of general data protection law with the particular obligations that apply when you operate in a regulated industry.

When sector-specific data protection obligations apply

Your data protection obligations go beyond UK GDPR when you fall within the definition of a telecommunications provider, authorised payment services provider, or electronic money institution. Each designation brings additional data protection requirements embedded in sector regulation.

If you provide public electronic communications networks or services, you must comply with the Communications Act 2003 as amended by the Telecommunications (Security) Act 2021, the Electronic Communications (Security Measures) Regulations (made under the TSA 2021), and the Privacy and Electronic Communications (EC Directive) Regulations 2003. PECR Regulation 21 and Regulation 22 create specific data protection duties around traffic data and location data that sit outside the main GDPR framework. Regulation 21 requires you to keep traffic data only for the duration necessary for billing or interconnection payments; Regulation 22 requires location data to be kept only for the duration necessary to provide a service or for billing purposes. These timing requirements differ from GDPR retention rules and create dual compliance obligations for the same data. The Telecommunications (Security) Act 2021 requires you to take measures to prevent and mitigate security compromises affecting customer data and network integrity. Ofcom oversees these duties, often in parallel with ICO data protection investigations. This creates a situation where a single incident (say, a data breach affecting telecommunications customers) may trigger both Ofcom security enforcement and ICO data protection enforcement.

If you are authorised to provide payment services or issue electronic money under the Financial Services and Markets Act 2000 (Regulated Activities) Order 2001, you must comply with the Payment Services Regulations 2017, the Electronic Money Regulations 2011, and FCA rules on Strong Customer Authentication (SCA). Strong Customer Authentication requires you to verify users through two or more elements from the categories of knowledge, possession or inherence when they access payment accounts or initiate high-risk payments. SCA data such as biometric templates or one-time passwords constitutes personal data under UK GDPR and attracts additional handling obligations. The FCA’s Technical Standards for SCA (set out in the FCA Handbook at PERG 2 Annex 1R) specify how SCA data must be transmitted and stored with secure encryption. The Payment Systems Regulator oversees open banking data sharing arrangements under which your firm may be required to share customer data with account information service providers, payment initiation service providers and fintech third parties at customer request. Open banking data sharing is a form of processor-related activity and brings controller responsibilities for the way customer data moves between authorised payment firms and third parties. The FCA Consumer Duty (COBS 2.1R) requires you to act in a manner which a reasonable consumer would regard as delivering good value, which includes treating customer data transparently and preventing unexpected uses of payment data for direct marketing or analytics without explicit consent.

If you provide Software as a Service, cloud infrastructure, or similar technology services, you must allocate your role correctly across the UK GDPR controller-processor landscape. Many SaaS vendors treat themselves as processors when they are actually joint controllers or sole controllers of customer data. Product design choices such as data minimisation, encryption, access controls and international transfer mechanisms determine your compliance posture and your customer’s ability to meet their GDPR obligations. When you store customer data in cloud regions outside the UK or EU, you create international transfer risks that require Standard Contractual Clauses, transfer impact assessments and supplementary technical controls. Article 25 UK GDPR requires data protection by design and by default; for technology companies, this means technical features such as encryption, access logging, subprocessor transparency and deletion capabilities must be built into products before customers use them, not retrofitted afterwards. Where your product incorporates AI or automated decision-making, Article 25 compliance requires you to design systems that allow data subjects to understand and challenge algorithmic decisions. Conversely, where your customers use your product to deliver their own services, you may inherit processor obligations under Article 28 UK GDPR and must ensure your contractual terms with customers allocate responsibilities clearly.

---

Why sector-specific compliance matters now

The Telecommunications (Security) Act 2021 created a new data protection overlay in telecoms regulation that did not exist before 2021. Ofcom now has specific duties to monitor and enforce security measures affecting customer data held by telecoms operators. When Ofcom investigates a telecoms provider over a data breach, the investigation often runs in parallel with an ICO investigation. This dual regulation means you cannot resolve one investigation in isolation; you must address the breach through both an Ofcom security lens and an ICO data protection lens. The obligation to prevent security compromises affecting customer data in real time, rather than merely to notify customers after a breach, creates a forward-looking compliance duty that goes beyond typical GDPR breach notification.

Open banking and variable recurring payments have created new data sharing obligations for payments firms that did not exist before 2019. The Payment Systems Regulator’s oversight of open banking data sharing means that payments firms must now document and justify every data transfer to third-party fintech providers. The FCA and PSR’s joint response to the government’s payments regulation recommendations, published in November 2024, confirms that open banking will expand to open finance, bringing further data sharing obligations for mortgages, investment products and insurance. For payments firms, this means data protection compliance now includes managing customer consent for data sharing with third parties, ensuring third parties meet processor obligations, and coordinating with PSR on how data flows are structured.

The Data (Use and Access) Bill, which had its first reading in the House of Lords on 23 October 2024, proposes to expand open banking and establish open finance across UK regulated financial services. This will increase data sharing obligations for payments firms and create new processor relationships. Until the legislation completes its passage and detailed regulations are published, payments firms cannot yet know the full scope of future obligations; however, the trend is clear: data sharing will increase and regulators expect firms to design data sharing infrastructure in real time.

Technology companies face an emerging obligation to design AI safety and data minimisation features into products from inception. The Data Protection Act 2018 (as amended by the Data Protection (Jurisdiction and Jurisdiction) (Amendment) Regulations 2019) places responsibility on processors to maintain technical security standards; Article 25 UK GDPR requires data protection by design; and the emerging UK AI governance framework (through the AI Act delegated acts and potential future UK legislation) expects AI providers to implement data protection controls. This confluence of obligations means that technology companies can no longer separate product design from compliance. The DUAA 2025 amendments to the UK GDPR, which come into force on 19 September 2025, recognise new Article 6(1)(ea) legitimate interests grounds for crime prevention and safeguarding. For technology and payments firms, this may reduce the compliance burden for some sector-specific processing. For example, a payments firm processing transaction data for fraud detection, or a technology company processing usage data for network security, may now rely on the recognised legitimate interest rather than seeking explicit consent. However, this advantage applies only if the processing is genuinely for the stated sector-specific purpose; abuse of the new ground may trigger regulatory attention.

---

Where sector-specific compliance goes wrong

The most common failure is to treat UK GDPR as the only data protection framework. Many organisations ignore that PECR applies to telecoms providers in parallel with UK GDPR, or that FCA data protection requirements sit alongside UK GDPR for payments firms. This creates gaps. For example, a telecoms provider that complies with UK GDPR retention periods but fails to apply PECR Regulation 21 retention rules for traffic data may find itself holding traffic data beyond what PECR permits, even though GDPR retention is compliant. Similarly, a payments firm that relies solely on GDPR consent for SCA data sharing may fail to meet the secure encryption and transmission requirements in the FCA Technical Standards.

A second failure is to ignore the interaction between sector regulators and data protection regulators. Telecoms providers often treat Ofcom security investigations as separate from ICO data protection investigations, leading to inconsistent remediation efforts. Payments firms sometimes assume that FCA authorisation means their data handling is approved, without checking that the FCA’s Technical Standards for SCA do not exempt them from UK GDPR Article 32 security obligations. This siloed approach creates regulatory friction; when an Ofcom investigation and an ICO investigation overlap, inconsistent responses can aggravate both regulators.

A third failure is a misalignment between processor and controller roles in SaaS arrangements. Many SaaS vendors position themselves as processors, which is correct in form but creates a false sense of compliance. A processor remains responsible for implementing technical security controls and must be capable of demonstrating compliance with Article 28 to customers. Where a SaaS vendor has not designed encryption, access controls or deletion capabilities into its product, it cannot meet its processor obligations regardless of its contract with the customer. Conversely, many SaaS vendors that handle customer data on behalf of customers in multiple jurisdictions (processing personal data on behalf of customers in the UK, EU and other regions) fail to recognise that they are actually joint controllers or sole controllers of some of that data, particularly when they use data for their own analytics, training models or security monitoring.

A fourth failure is the assumption that Strong Customer Authentication data is outside data protection scope. Many payments firms treat SCA data such as biometric templates or one-time passwords as authentication data rather than personal data, failing to apply GDPR storage and deletion requirements. This is incorrect. SCA data is personal data and must be retained only for the duration necessary for the authentication purpose; indefinite retention of biometric templates for “future security” is not compliant.

A fifth failure is to ignore PECR traffic and location data rules when undertaking analytics, marketing or network optimisation. Telecoms providers often re-use traffic data or location data for purposes beyond billing (such as network analytics or direct marketing) without recognising that PECR Regulation 21 and 22 prohibit this use. The fact that GDPR might permit such re-use under a legitimate interests basis does not override the specific prohibition in PECR.

---

What sector-aware data protection looks like

Bratby Law brings together three practice areas: telecoms regulation, data protection and payments regulation. This combination creates a structural advantage when advising on sector-specific data protection compliance. Many general data protection advisors understand UK GDPR well but lack sector regulation expertise; many sector regulators’ advisors understand their sector well but lack data protection depth. The intersection of the two requires specialist attention.

For telecoms providers, sector-aware compliance means mapping PECR rules (traffic data retention, location data retention, direct marketing rules for electronic messages) alongside UK GDPR rules. The starting point is to identify which data falls under PECR Regulation 21 (traffic data: calling parties’ telephone numbers, called parties’ numbers, charge cards used, service type, time and duration of calls, data volume transmitted, and SIM card serial numbers), which data falls under PECR Regulation 22 (location data: geographic position of mobile devices) and which data falls under general GDPR. PECR traffic data must be deleted when billing and interconnection queries are resolved. PECR location data must be deleted when the service is provided. General customer data may be retained for longer periods if a legitimate business purpose exists. The Telecommunications (Security) Act 2021 layers further obligations on top: data security measures must be proportionate to the risk, incident response procedures must be in place, and suppliers must be vetted. A telecoms provider that complies with all three frameworks simultaneously is rare; most operate in a reactive posture, responding to regulatory findings rather than designing integrated compliance programmes.

For payments firms, sector-aware compliance means mapping FCA SCA rules, FCA Consumer Duty expectations and PSR open banking oversight alongside UK GDPR. The starting point is to identify which customer data triggers SCA (high-value transactions, access to payment accounts), how that data must be transmitted (secure encryption per FCA Technical Standards), how long it must be retained (only for the period the SCA function is needed) and whether it can be shared with open banking third parties (it can, but only with explicit customer consent and after transfer risk assessment). FCA Consumer Duty requires data transparency; when a payments firm uses customer data for direct marketing, analytics or fraud detection, customers must be able to understand this use and withdraw consent easily. The PSR’s expansion of open banking toward open finance means payments firms must also build data sharing infrastructure that allows customers to share mortgages, investments and insurance data with third parties at their request, and document the processor relationships that result.

For technology companies, sector-aware compliance means allocating controller and processor roles correctly, designing encryption and access controls into products from inception, and managing international transfers through a combination of Standard Contractual Clauses and supplementary technical measures. Where a SaaS vendor processes customer data on behalf of multiple customers in multiple jurisdictions, the vendor must recognise that it may be a joint controller with customers for some purposes (say, security monitoring or abuse detection that benefits the vendor’s platform) and a processor for other purposes (data processing on behalf of the specific customer). Building this dual role into contract terms from the start prevents disputes and regulatory friction later.

A cross-sector transaction often brings sector-specific data protection issues to the forefront. For example, when a fintech payments startup acquires a telecoms customer relationship management tool, the acquiring firm inherits data processing obligations under both the Payment Services Regulations and the Communications Act 2003. A thorough regulatory due diligence process must map which data falls under which framework, identify gaps in existing compliance, and design integrated remediation.

---

When to instruct specialist sector-specific data protection counsel

The intersection of sector regulation and data protection law is the point at which sector-specific expertise becomes critical. General data protection advisors can guide UK GDPR compliance; general telecoms, payments or technology advisors can guide sector regulation compliance. Sector-specific data protection counsel bridges the two.

You should instruct specialist sector-specific data protection counsel when a telecoms provider faces investigation by both Ofcom and the ICO in relation to the same security incident, when a payments firm navigates FCA and PSR rules that affect how customer data can be shared with fintech third parties, when a technology company structures a complex SaaS arrangement with processor and controller roles split across multiple jurisdictions, or when any regulated entity enters a transaction where data protection compliance cannot be separated from sector regulatory compliance.

You should also seek specialist counsel when you operate across multiple sectors. A payment institution that provides telecommunications services must navigate PECR, TSA 2021, Payment Services Regulations and UK GDPR simultaneously. A technology company that provides data infrastructure to payments firms must ensure its product design meets FCA Technical Standards for secure transmission while also meeting UK GDPR security standards. A telecoms provider that is also subject to FCA requirements because it offers payment services (for example, a mobile operator offering mobile payments) must coordinate between Ofcom and FCA on overlapping compliance obligations.

---

FAQs

Do we need to comply with PECR if we comply with UK GDPR?

PECR is not a subset of UK GDPR; it is a parallel framework. PECR applies to electronic communications service providers (telecoms firms, internet service providers and certain technology platforms). Even if a telecoms provider is fully GDPR-compliant, it may breach PECR by retaining traffic data beyond the period allowed by Regulation 21 or using location data for purposes forbidden by Regulation 22. Telecoms providers must meet both frameworks simultaneously. The simplest approach is to map each data type to the relevant framework: traffic data is ruled by PECR Regulation 21 first, location data by PECR Regulation 22 first, and only data that falls outside PECR is governed by GDPR alone.

If a customer consents to data sharing through open banking, do we still need a data protection impact assessment?

Yes. Customer consent is one lawful basis for processing under Article 6 UK GDPR, but Article 35 requires a Data Protection Impact Assessment when processing is likely to result in high risk to data subjects. Open banking data sharing creates high risk because customer financial data is transferred to third-party fintech providers that may have different security standards, may operate in different jurisdictions and may be acquired by larger firms in the future. The DPIA must address whether the third-party processor meets UK GDPR standards, whether Standard Contractual Clauses and supplementary technical measures are needed for international transfers, and whether the customer has a right to deletion once the open banking consent is withdrawn. Consent alone does not eliminate the need for a DPIA.

Can we use SCA biometric data for purposes other than authentication?

No, unless you obtain separate explicit consent for that purpose. SCA data such as fingerprint templates or iris scans is personal data under UK GDPR. The FCA Technical Standards for SCA require it to be encrypted and used only for authentication. If you want to use SCA biometric data for other purposes (fraud detection, behavioural analytics, or model training), you must obtain separate consent and assess whether the secondary purpose is compatible with the original authentication purpose under Article 6(4). The ICO’s guidance on purpose limitation makes clear that re-using biometric data for purposes the customer did not expect is high risk and often incompatible.

Is our firm a processor or a controller when we provide SaaS platform?

The answer depends on how much discretion you exercise over customer data. If you process data solely on instructions from your customer and do not use the data for your own purposes, you are a processor. If you use customer data for your own security monitoring, abuse detection, training machine learning models or analytics, you are a joint controller with your customer for those purposes. If you decide what data to collect and how to use it, you are a sole controller. Many SaaS vendors operate in a grey area: they are processors for the core service but joint controllers for security monitoring. Clarity is essential because joint controllers have independent GDPR obligations to data subjects and must document the split with customers in writing.

When must we apply supplementary technical measures for international data transfers?

The UK GDPR does not ban transfers to non-adequate third countries, but Article 46 requires an appropriate safeguard such as Standard Contractual Clauses (SCCs) or Binding Corporate Rules. Supplementary technical measures are additional to SCCs and are required when the third country’s laws create a risk that public authorities will access the data (for example, mass surveillance laws) and the SCCs alone cannot address that risk. The ICO’s guidance on international transfers (updated March 2024) makes clear that supplementary measures are not optional; they are expected where there is a genuine transfer risk. For technology companies storing customer data in the United States or other jurisdictions with mass surveillance frameworks, supplementary technical measures such as encryption with customer-held keys (where the provider does not hold decryption keys) are now standard practice.

Do we need to notify the ICO of a security incident affecting SCA data?

Yes, under Article 33 UK GDPR. A breach of SCA data such as authentication credentials or biometric templates must be reported to the ICO within 72 hours. The FCA has not published separate breach notification requirements for SCA data; ICO notification is the standard. However, payments firms must also consider whether the breach triggers FCA notification rules under COBS 20. A payments firm that suffers a security breach affecting customer payment instruments must notify both the ICO and the FCA. Telecoms providers that store SCA data (for example, as part of a mobile payment service) must notify both the ICO and Ofcom.

Independent directory rankings

Our specialist expertise is recognised in major independent legal directories:

• Chambers & Partners: Rob Bratby is ranked as a band 2 lawyer in the UK Guide 2026 in the “Telecommunications” category: Chambers
• The Legal 500: Rob Bratby is listed as a “Leading Partner – Telecoms” in London (TMT – IT & Telecoms): The Legal 500
• Lexology: Rob Bratby is featured on Lexology’s expert profiles as a Global Elite Thought Leader for data: Lexology

Representative experience

Recent and representative matters include:

• Advised a telecoms provider on the interaction between UK GDPR obligations and the PECR requirements for traffic data, location data and subscriber directories.
• Designed a How do data protection rules vary by sector? compliance programme for a payments institution, addressing both UK GDPR requirements and the FCA’s expectations on customer data handling.
• Advised a health-tech company on the processing of special category What are the rules for processing health data? under Article 9 and the DPA 2018 Schedule 1 conditions, including the substantial public interest and medical purposes conditions.
• Reviewed the data protection arrangements for a smart metering programme, addressing the interaction between energy sector data access rules and UK GDPR obligations.
• Advised an insurance company on the lawful basis for profiling using health and genetic data, assessing the Article 9 conditions and the ICO’s guidance on insurance-specific processing.

Related data protection pages

• Data Protection Impact Assessments
• UK/EU Data Protection Divergence