PECR and cookies
The Privacy and Electronic Communications (EC Directive) Regulations 2003 (PECR), as amended by the Data (Use and Access) Act 2025, govern the use of cookies and similar storage technologies on websites accessed from the UK. PECR Regulation 6 requires consent for any storage of, or access to, information on a user’s terminal equipment, with an exemption for storage that is strictly necessary for a service explicitly requested by the user.
Lending Agent Oversight uses one cookie. It falls inside the strictly-necessary exemption. There are no analytics cookies, no marketing cookies, no third-party tracking, and no fingerprinting.
The session cookie
Section titled “The session cookie”| Attribute | Value |
|---|---|
| Name | lao_session |
| Purpose | Authentication state for the workspace |
| Type | First-party, session-scoped, opaque server-generated id |
| Lifetime | 12 hours sliding, 7-day absolute cap |
HttpOnly | true |
Secure | true |
SameSite | Lax |
Path | / |
Domain | The principal-firm-specific tenant domain (default oversight.<operator-domain>) |
The cookie carries no personal data. It is an opaque server-generated identifier that resolves on the server to a session row in Postgres, which holds the user id, tenant id, role, AR id (where the user is an AR-user), creation time, expiry, last-seen time, IP, and user-agent. The cookie’s value tells an attacker nothing about the user without server access.
The session lifetime supports the workspace’s access patterns: a regulated user may work in the workspace through the day, with a sliding refresh on each interaction; the absolute cap forces a fresh sign-in plus TOTP at most once a week.
Why this is strictly necessary
Section titled “Why this is strictly necessary”PECR Regulation 6(4) exempts cookies whose use is strictly necessary for a service explicitly requested by the user. The session cookie is necessary for the workspace’s authentication: without it, every request would require the user to re-enter their email, password, and TOTP, which is not feasible for a workspace used hourly by regulated individuals.
The ICO’s guidance on PECR confirms that authentication cookies and session-state cookies fall inside the strictly-necessary exemption. The cookie is first-party, session-scoped, and used solely for the user’s request to access the workspace.
No consent banner is required. A consent banner that asked for permission to set the strictly-necessary cookie would be misleading; the user cannot use the workspace without it.
What the workspace does not use
Section titled “What the workspace does not use”- Analytics cookies. No Google Analytics, no Plausible, no Mixpanel, no first-party rollup of behavioural data via cookies.
- Marketing or advertising cookies. None.
- Third-party tracking pixels. None.
- Local storage for personal data. The AR-user’s MI return draft is held in
localStorageunder a key bound to the AR id, but the contents are the user’s own draft and the storage is on the user’s own device. The draft is removed on submit. This is not a PECR-engaging use because nothing is read back from the device by the platform. - Browser fingerprinting or device fingerprinting. None.
- Beacon-style telemetry. None.
The marketing landing page
Section titled “The marketing landing page”The marketing landing page (/, /demo) is hosted on the same Vercel deployment and uses no cookies. There is no analytics on the landing page in v1. If the operator adds product analytics to the landing page in a future release, the addition will be:
- A consent-required cookie (PECR Regulation 6(1) consent), with a banner.
- A clearly distinguished sub-processor (added to sub-processors under the 30-day notice window).
- Anonymised at source where the chosen analytics tool supports it.
- Not extended into the authenticated workspace.
The principal firm’s own marketing site, where it links to the workspace, is the firm’s own responsibility under PECR.
CSRF protection
Section titled “CSRF protection”The workspace uses a double-submit pattern for CSRF protection on write paths. A csrfToken is returned by GET /api/me and read from the response body by the client; write requests carry the token in the X-CSRF-Token header. The token is not a cookie; it is a server-generated value tied to the session.
This avoids a CSRF cookie that would itself need a PECR consideration. The session cookie is the only cookie set by the workspace.
Email tracking
Section titled “Email tracking”Transactional emails sent via Postmark do not carry tracking pixels or click-tracking. The platform operator disables open-tracking and click-tracking at the Postmark template level. A principal firm that wishes to enable these for its own operational reasons can do so as a per-tenant configuration; the firm becomes the controller of the click-tracking data and adapts its own privacy notice.
ePrivacy under the Data (Use and Access) Act 2025
Section titled “ePrivacy under the Data (Use and Access) Act 2025”The DUA Act 2025 amended PECR’s cookie regime, in particular liberalising the consent rules for low-risk analytics cookies under DUA’s revised Regulation 6A. The workspace does not rely on the new exemption; the strictly-necessary exemption already covers the session cookie, and there are no analytics cookies in scope. The DUA changes do not affect the workspace’s posture in v1.
Summary
Section titled “Summary”One cookie. First-party, session-scoped, opaque, HTTP-only, Secure, SameSite=Lax. Strictly necessary under PECR Regulation 6(4). No banner. No analytics. No tracking. The PECR position is recorded here so the principal firm’s privacy notice and any audit response can reference it directly.