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. A telecoms provider must comply with the PECR duties on traffic and location data and with the security duties under the Telecommunications (Security) Act 2021. A payment services firm must apply the FCA authentication rules, meet the open banking data sharing requirements overseen by the PSR, and account for the Consumer Duty in the way it uses customer information. A SaaS provider must allocate controller and processor roles to match what it does with customer data, and must manage the international transfer risk its own product design creates.

Where a sector-specific obligation applies to an AI-enabled product, the sector regulator and the ICO can both be engaged on the same product. How Ofcom, the FCA, the PSR and the CMA use their existing powers over AI systems is set out at UK AI Regulation: What the Law Actually Says.

When sector-specific data protection obligations apply

Your data protection obligations go beyond UK GDPR when you are the provider of a public electronic communications network or service, an authorised payment institution or an 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 2022, and the Privacy and Electronic Communications (EC Directive) Regulations 2003. PECR Regulation 7 and Regulation 14 create specific data protection duties around traffic data and location data that sit outside the main UK GDPR framework. Regulation 7(1) requires traffic data to be erased or anonymised once it is no longer needed to transmit a communication, and regulation 7(2) and (5) permit it to be kept for the payment of charges or for interconnection payments only until the period for bringing legal proceedings over those payments ends, or until such proceedings are finally determined. Regulation 14 is stricter and says nothing about billing: location data may be processed only where the user or subscriber cannot be identified from it, or where processing is necessary to provide a value added service with that person’s consent. These timing requirements differ from UK GDPR retention rules and create dual compliance obligations for the same data. Section 105A(1) of the Communications Act 2003, inserted by the Telecommunications (Security) Act 2021, requires the provider of a public electronic communications network or service to take appropriate and proportionate measures to identify the risks of security compromises occurring, to reduce those risks and to prepare for a compromise; section 105C then requires it to prevent, and to remedy or mitigate, the adverse effects of a compromise once one has occurred. A security compromise includes anything occurring in connection with the network or service that compromises the confidentiality of data stored by electronic means, or causes such data to be lost or altered. Ofcom must seek to ensure that providers comply with those duties, under section 105M. 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 as a payment institution under regulation 6 of the Payment Services Regulations 2017, or as an electronic money institution under regulation 6 of the Electronic Money Regulations 2011, you must comply with those Regulations and with the strong customer authentication requirements they impose. Authorisation for payment services and for issuing electronic money is not granted under the Financial Services and Markets Act 2000 (Regulated Activities) Order 2001, and Part 4A permission under FSMA is a different thing: which Handbook material reaches you turns on that distinction. Regulation 100(1) of the Payment Services Regulations 2017 requires strong customer authentication where a payment service user accesses its payment account online, initiates an electronic payment transaction, or carries out any action through a remote channel which may imply a risk of payment fraud or other abuses. Authentication uses two or more elements from the categories of knowledge, possession and inherence, and regulation 100(2) requires dynamic linking to a specific amount and payee for an electronic remote payment transaction. SCA data such as biometric templates or one-time passwords constitutes personal data under UK GDPR and attracts additional handling obligations. Regulation 100(3) requires you to maintain adequate security measures to protect the confidentiality and integrity of payment service users’ personalised security credentials, and the technical standards made under regulation 106A set the exemptions from strong customer authentication and the requirements for common and secure methods of communication. 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. Principle 12 in PRIN 2.1.1R requires a firm to act to deliver good outcomes for retail customers, and PRIN 2A carries the detailed obligations. It reaches payment institutions and electronic money institutions because PRIN 3.2.1B applies PRIN to the provision of payment services and to the issuing of electronic money, and PRIN 2A.1.7 reads the references to regulated activities in that chapter as including both. The consumer understanding and price and value limbs of the Duty bear directly on how transparent you are about the use of customer data. FCA Handbook material is reproduced with the acknowledgement of FCA copyright.

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 framework. A SaaS vendor’s role is determined by its actual processing activity, not by how it labels itself: a vendor operating as a processor in form may in fact be a joint controller or sole controller 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 UK GDPR obligations. When you store customer data outside the UK you make a restricted transfer, and Article 46(1A) UK GDPR permits it only where an appropriate safeguard is in place and you, acting reasonably and proportionately, consider that the data protection test in Article 46(6) is met. The UK safeguards are the International Data Transfer Agreement, the Addendum to the EU standard contractual clauses and UK binding corporate rules; the EU standard contractual clauses are not themselves a UK safeguard. The ICO calls the assessment a transfer risk assessment. 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 takes significant decisions about people solely by automated processing, the duty to give information about the decision and to allow representations, human intervention and contest is in Article 22C rather than Article 25. Article 25 is the reason those safeguards have to be built into the product rather than bolted on afterwards. 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

A public electronic communications provider must take appropriate and proportionate measures to identify, reduce and prepare for the risks of security compromises under section 105A of the Communications Act 2003, and to prevent and then remedy or mitigate their adverse effects under section 105C; Ofcom must seek to ensure compliance under section 105M. When Ofcom investigates a telecoms provider over a data breach, the investigation often runs in parallel with an ICO investigation. You must answer to Ofcom on the security failure and to the ICO on the personal data, and you cannot settle one investigation and leave the other. Because section 105A is a duty to identify and reduce risks before anything happens, rather than a duty to report after the event, it is forward-looking in a way that the UK GDPR breach notification duty in Article 33 is not.

Open banking and variable recurring payments have created data sharing obligations for payments firms. The Payment Systems Regulator’s oversight of open banking data sharing means a payments firm has to be able to account for the customer data it shares with third-party providers. The FCA and the PSR replied jointly in November 2024 to the government’s recommendations on payments regulation. Any extension from open banking to open finance will take legal effect through the smart data regulations described below, not through that reply. 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) Act 2025, which received Royal Assent on 19 June 2025, established a framework for smart data schemes in Part 1 of the Act, headed access to customer data and business data; Part 2 is about digital verification services. Section 1(1) confers the powers on the Secretary of State and the Treasury, and data regulations under sections 2 and 4 may require a data holder to provide customer data or business data to a person at the customer’s request. Secondary legislation and accreditation frameworks are required before each scheme takes effect; the detailed obligations for open finance are not yet in force. Payments firms should monitor the secondary legislation programme and design data sharing infrastructure in anticipation of the expanded regime.

Technology companies face a developing obligation to design AI safety and data minimisation features into products from inception. Article 32(1) UK GDPR places the duty to implement appropriate technical and organisational security measures on the controller and the processor alike, and it does so on its own. Sections 22 to 28 of the Data Protection Act 2018 are not the companion provisions: they sit in Part 2, Chapter 3, which deals with exemptions for manual unstructured processing and for national security and defence, section 22 was omitted on 31 December 2020, and section 28(2) disapplies Article 32 for national security and defence processing rather than supplementing it; Article 25 UK GDPR requires data protection by design; and there is no separate UK AI statute, so an AI-enabled product is regulated in the UK through data protection law and the existing powers of the sector regulators. The EU AI Act is EU law: it reaches a UK company only where that company places an AI system on the EU market or the system’s output is used in the EU. 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 came into force on 5 February 2026, added Article 6(1)(ea), the recognised legitimate interests basis, so the lawful bases in Article 6(1) now number seven rather than six. Article 6(5) allows reliance on it only where the processing meets one of the five conditions in Annex 1: disclosure on request for another person’s public interest task; national security, public security or defence; responding to an emergency; detecting, investigating or preventing crime, or apprehending or prosecuting offenders; and safeguarding a vulnerable individual. The closing words of Article 6(1) keep it away from public authorities acting in the performance of their tasks, and Article 22B(4) bars any significant solely automated decision taken in reliance on it. So a payments firm processing transaction data to detect fraud may be able to reach the crime condition, and where it does the balancing test falls away. A technology company processing usage data for network security cannot: Article 6(11)(c) gives the security of network and information systems as an example of an ordinary legitimate interest under Article 6(1)(f), where the balancing test still applies.

---

Common sector-specific compliance failures

UK GDPR is not the only data protection framework. PECR applies to telecoms providers in parallel with UK GDPR, and FCA data protection requirements sit alongside UK GDPR for payments firms. Treating UK GDPR compliance as sufficient on its own creates gaps. For example, a telecoms provider that complies with UK GDPR retention periods but fails to apply the PECR regulation 7 rules for traffic data may find itself holding traffic data beyond what PECR permits, even though UK GDPR retention is compliant. Similarly, a payments firm that relies solely on UK GDPR consent for SCA data sharing may fail to meet the secure encryption and transmission requirements in the FCA Technical Standards.

Sector regulators and data protection regulators interact. Ofcom security investigations and ICO data protection investigations frequently run in parallel over the same incident, and remediation must address both in a consistent way. FCA authorisation does not mean a payments firm’s data handling is approved; the FCA’s Technical Standards for SCA do not exempt firms from UK GDPR Article 32 security obligations. Where an Ofcom investigation and an ICO investigation overlap, an operator that gives the two regulators different accounts of the same incident makes both investigations harder for itself.

Processor and controller roles in SaaS arrangements require careful allocation. A SaaS vendor that positions itself as a processor is correct in form only where it in fact meets processor obligations: 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, a SaaS vendor that handles customer data on behalf of customers in multiple jurisdictions (processing personal data on behalf of customers in the UK, EU and other regions) may in fact be a joint controller or sole controller of some of that data, particularly where it uses data for its own analytics, training models or security monitoring.

Strong Customer Authentication data is not outside data protection scope. The UK GDPR storage and deletion rules apply in full to SCA data such as a biometric template or a one-time password. There is no lighter authentication-only standard. 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.

The PECR traffic and location data rules apply to analytics, marketing and network optimisation, not only to billing. The provisions are regulations 7 and 14, not regulations 21 and 22, and neither is an outright prohibition. Regulation 7(3) permits traffic data to be processed for marketing electronic communications services or for providing a value added service, but only where the subscriber or user has previously notified consent, only for as long as that purpose needs, and with a right to withdraw consent at any time. Regulation 14(2) permits location data to be processed only where the person cannot be identified from it, or where processing is necessary to provide a value added service with that person’s consent, once the information required by regulation 14(3) has been given. A legitimate interests basis under the UK GDPR is not a substitute for that consent.

---

What sector-aware data protection looks like

Bratby Law advises on telecoms regulation, data protection and payments regulation. A sector-specific data protection question is answered by reading the sector rules and UK GDPR together.

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 is traffic data within the regulation 2(1) definition and so falls under regulation 7, which data is location data and so falls under regulation 14, and which data falls under the UK GDPR alone. Traffic data must be erased or anonymised once it is no longer needed to transmit the communication, and may be kept for charges or interconnection payments only until the period for bringing legal proceedings over those payments ends or such proceedings are finally determined, under regulation 7(1), (2) and (5). Location data may be processed only on the regulation 14(2) conditions. General customer data may be retained for longer periods if a legitimate business purpose exists. The Electronic Communications (Security Measures) Regulations 2022 add specific duties, each qualified by what is appropriate and proportionate: regulation 7 requires the risks arising from third party suppliers to be identified and reduced and to be managed through contractual arrangements, regulation 9 requires means and procedures to identify a compromise and to recover from it, regulation 10 requires a security policy with board-level responsibility for its implementation, and regulation 11 requires a written assessment of the overall risk at least once every twelve months.

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 transactions trigger strong customer authentication under regulation 100(1), which is online access to a payment account, the initiation of an electronic payment transaction and any remote action that may imply a risk of payment fraud rather than high value alone, how the personalised security credentials are protected under regulation 100(3), how long the data is retained and whether it can be shared with open banking third parties (it can, but only with explicit customer consent and after transfer risk assessment). The Consumer Duty carries a consumer understanding obligation in PRIN 2A, so a payments firm using customer data for direct marketing, analytics or fraud detection should be able to show that its retail customers can understand what is being done and can act on it. 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 buyer inherits the data protection position of what it buys. A fintech payments firm that acquires a telecoms customer relationship management tool takes on 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

A firm that must satisfy both its sector regulator and the ICO on the same data needs advice on both regimes at once. Advice on UK GDPR alone, or on sector regulation alone, leaves the overlap between them unanswered.

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 must apply FCA and PSR rules to the sharing of customer data 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 also provides telecommunications services must comply with PECR, the TSA 2021, the Payment Services Regulations and UK GDPR at the same time. 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 UK GDPR-compliant, it may breach PECR by retaining traffic data beyond the period allowed by regulation 7, or by processing location data outside the conditions in regulation 14. Regulations 21 and 22 are the direct marketing rules, for calls and for electronic mail respectively. Telecoms providers must meet both frameworks simultaneously. The simplest approach is to map each data type to the relevant framework: traffic data falls under PECR regulation 7 first, location data under PECR regulation 14 first, and only data outside PECR is governed by UK 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 the UK International Data Transfer Agreement or the Addendum is needed for any international transfer, and whether the data protection test in Article 46(6) is met, 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. Article 6(4) was omitted from the UK GDPR on 5 February 2026 and the compatibility test is now in Article 8A, which lists the factors to be taken into account and the cases treated as compatible; where the data was collected on the data subject’s consent, Article 8A(4) narrows those cases further. Re-using a biometric template for a purpose the customer did not expect is unlikely to satisfy that test.

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 UK 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 countries without adequacy regulations, but Article 46(1A) allows one only where an appropriate safeguard is in place and the controller or processor, acting reasonably and proportionately, considers that the data protection test in Article 46(6) is met. Articles 44 and 45 were omitted on 5 February 2026, and adequacy is now a matter of regulations made by the Secretary of State under Articles 45A and 45B. The UK safeguards are the International Data Transfer Agreement, the Addendum to the EU standard contractual clauses and UK binding corporate rules, issued under Article 46(2)(b) and (d) read with section 119A of the DPA 2018; the EU standard contractual clauses are not themselves a UK safeguard. The data protection test asks whether, after the transfer, the protection for the data subject would be materially lower than under the UK regime. That is the exercise the ICO’s international transfers guidance still calls a transfer risk assessment, and it is where the need for technical measures such as encryption is assessed. 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. A payments firm must also consider regulation 99(1) of the Payment Services Regulations 2017, which requires a payment service provider that becomes aware of a major operational or security incident to notify the FCA without undue delay, in the form and manner the FCA directs in SUP 15.14; regulation 99(3) requires it to inform its payment service users where the incident has or may have an impact on their financial interests. COBS 20 is not the provision: that chapter is about with-profits business. A telecoms provider must inform Ofcom under section 105K of the Communications Act 2003, but only of a security compromise that has a significant effect on the operation of its network or service, so a breach of stored authentication data does not engage Ofcom automatically.

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 for Telecoms in London (TMT: IT and Telecoms). The Legal 500
• Lexology: Rob Bratby is recognised in the Lexology Index as a Global Elite Thought Leader for telecoms and media, and as a Thought Leader for data privacy and protection: 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.
• Maintains the data protection compliance framework for a payments industry body, covering DPIAs, privacy notices and data processing agreements.
• Advises a contact centre technology company on the data protection framework for AI-enabled analytics across its cloud platform.
• Built a dual UK and EU GDPR documentation suite for a data services company, including international transfer assessments.
• Advised a data analytics company on the sector-specific interaction between the Wireless Telegraphy Act 2006, PECR and UK GDPR for a new data-collection product.

Related data protection pages

See also our other data protection pages:

UK GDPR Compliance
Lawful Basis and Legitimate Interests
Data Protection Impact Assessments
Data Governance, Transfers and Accountability
UK/EU Data Protection Divergence
AI and Automated Decision-Making
The EU AI Act: what UK businesses need to know
Data Breach Response and ICO Notification
PECR and ePrivacy

Why Choose Bratby Law?

Telecoms, data protection and payments regulation lawyers

Bratby Law advises on telecoms regulation, data protection, payments regulation, transactions and digital regulation across the communications, financial services and technology sectors.