PECR Compliance

Disclaimer: The information below is not legal advice, and we don't accept any legal liability. We have received our own legal advice, and this page is our interpretation of the law. If you have any concerns regarding PECR compliance, please forward this page to your legal team.

What is PECR?

PECR (the Privacy and Electronic Communications Regulations 2003) is the UK's national implementation of the EU's ePrivacy Directive (2002/58/EC). It covers electronic marketing (calls, SMS, email), the security of public communications networks, and, most relevant for analytics, the rules around cookies and similar technologies that access or store information on end-user devices.

PECR is often called the UK's "cookie law," but its scope is broader than cookies. It applies to any technology that stores information in, or reads information from, a user's terminal equipment: their device, whether that's a laptop, phone, tablet, smart TV, or anything else.

A note on Brexit. Before the UK left the EU, PECR tracked changes to the underlying ePrivacy Directive automatically. Now that the UK has diverged, if the EU finalises the ePrivacy Regulation (the planned successor to the Directive), the UK will not be legally required to follow it. The UK may elect to align with it, or it may develop its own framework. We treat PECR as a distinct instrument from the ePrivacy Directive and monitor both independently.

Does PECR apply to you?

If you are operating a website that processes any data about UK residents, it is reasonable to assume PECR applies. The ICO (Information Commissioner's Office), the UK's data protection regulator, takes PECR seriously and has issued enforcement action against analytics deployments that use cookies without consent. We build Clerion AI with PECR compliance in mind regardless of where our customers are based.

What does PECR require?

The relevant provision is Regulation 6(1) and 6(2) of The Privacy and Electronic Communications (EC Directive) Regulations 2003:

6(1) Subject to paragraph (4), a person shall not use an electronic communications network to store information or to gain access to information stored in the terminal equipment of a subscriber or user unless the requirements of paragraph (2) are met.

(2) The requirements are that the subscriber or user of that terminal equipment: (a) is provided with clear and comprehensive information about the purposes of the storage of, or access to, that information; and (b) is allowed to refuse the storage of or access to that information.

In plain terms: if your analytics tool stores anything on your visitors' devices, or reads anything from them, you must tell visitors clearly what you are doing and give them the ability to refuse. This is the consent requirement, and it applies to cookies, localStorage, sessionStorage, and any other form of device storage or access.

Is Clerion AI PECR compliant?

We believe so, and we have taken a similar approach to our ePrivacy Directive analysis. We are not lawyers and cannot give legal advice, but here is our position in full.

What we do NOT do

No analytics cookies. The Clerion tracking script does not set any cookies for analytics purposes. Not first-party, not third-party, not session, not persistent. This is the most common PECR compliance issue for analytics platforms, and it does not apply to Clerion.

No device fingerprinting. We do not read canvas fingerprints, WebGL renderer strings, installed font lists, plugin inventories, audio processing characteristics, or any of the multi-point device signatures used by advertising technology to build persistent cross-device profiles. The ICO specifically calls out fingerprinting as a "similar technology" subject to PECR's consent requirement, and it is not something we do.

No persistent cross-visit tracking without consent. We do not build a profile linking your visitors' activity across multiple visits without their explicit consent. Without consent, every visit is treated independently.

What we do, and our legal basis for it

sessionStorage: session continuity. The SDK writes a session identifier to sessionStorage to group page events within a single browsing session (e.g., page views, scrolls, clicks on the same visit). sessionStorage is automatically cleared when the browser tab is closed. It cannot be accessed by other websites, cannot be shared across tabs, and does not persist between visits.

We believe this falls within or very close to the "strictly necessary" exception in Regulation 6(4): it is necessary to deliver the analytics service the site operator has requested, and it has no material privacy impact on visitors given its strictly ephemeral, same-tab scope. That said, we disclose it here transparently rather than relying on the exception silently.

Device properties for aggregate classification. The SDK reads a limited set of device properties from the browser environment: screen dimensions, viewport size, device pixel ratio, orientation, browser language, timezone, and basic network connection type. These are used to classify visitors into device categories (mobile, tablet, desktop) and to enrich aggregate audience intelligence. They are not combined into a fingerprint, not linked to a persistent identifier without consent, and not shared with any advertising network.

Reading these properties does constitute "gaining access to information in terminal equipment" under Regulation 6(1). This is why Clerion ships with a built-in consent architecture: if your use of these properties requires consent under your legal team's assessment, the consent layer is ready to use out of the box.

localStorage: persistent visitor ID, consent-gated. The SDK can optionally create a persistent visitor identifier stored in localStorage, used to count returning visitors. This is strictly gated behind explicit user consent in the SDK source code: if consentStatus !== true, no localStorage write occurs. Consent is recorded in a first-party preference cookie (clerion_consent) and honoured on all subsequent visits. Revoking consent immediately deletes the stored identifier.

Without consent, no persistent identifier is created and no localStorage is written.

The built-in consent mechanism

Clerion's SDK ships with a consent layer designed to meet PECR's requirements. Key behaviours:

• requireConsent: true is the default. Persistent tracking is off until consent is given.
• Consent preference stored in a first-party cookie. Storing a user's stated consent preference is considered strictly necessary. It requires no further consent to set.
• Revocation clears stored data. Withdrawing consent immediately deletes the persistent visitor ID from localStorage.
• A ready-to-use consent banner is included. The SDK ships alongside clerion-consent-banner.js, a consent UI component that wires directly into the SDK's consent API. Site owners do not need to build a custom consent flow.
• Session-only mode without consent. Operators can enable session-level aggregate analytics (using sessionStorage only) without requiring a consent decision, providing basic traffic insight while respecting visitor choice.

Browser privacy signals

The SDK honours both recognised privacy signals:

• Global Privacy Control (GPC): navigator.globalPrivacyControl === true immediately suppresses all tracking: no events fired, no storage written.
• Do Not Track (DNT): navigator.doNotTrack === '1' is treated as a privacy opt-out. DNT has no legal standing under PECR, but the ICO has encouraged respecting it as a matter of good practice.

Both signals are checked before any activity begins and both override any site-level configuration.

PECR and UK GDPR

PECR and UK GDPR work in parallel. PECR governs access to and storage on terminal equipment. UK GDPR governs the processing of personal data collected thereafter. If Clerion's tracking script sets no cookies and you are not using the persistent visitor ID feature, your PECR exposure is minimal. Any personal data processing that does occur (primarily hashed IP addresses on our EU server infrastructure) is governed by UK GDPR, for which we maintain a Data Processing Agreement and process data under legitimate interest.

What about Google Analytics?

As the ICO has stated clearly: analytics cookies are not exempt from PECR. Google Analytics deploys cookies. If you use Google Analytics on a website that has UK visitors and you have not obtained active, informed consent for those cookies, you may not be compliant with PECR. Consent through browser settings does not satisfy the UK requirement. It must be actively given by the user for the specific purpose.

Clerion sets no analytics cookies. Our architecture avoids the problem rather than managing it.

Looking ahead

The UK's approach to data and privacy law is evolving post-Brexit. The Data (Use and Access) Act and related reforms may reshape the framework within which PECR sits. We are watching these developments closely. Whatever the regulatory landscape becomes, Clerion's privacy-first architecture (cookieless, no fingerprinting, consent-gated persistence, GPC/DNT-aware) is designed to remain compliant, with headroom beyond the minimum the current law requires.

Summary