Data handling

Oblifee is a compliance tool, so the data it holds is deliberately narrow: enough to work out what you owe and to prepare your submissions, and no more. This page sets out what is stored, what is not, and how requests about that data are handled.

What Oblifee stores

Category	Examples	Why it is held
Products	SKU, name, category, barcode, dimensions, net weight	To identify what you place on the market
Packaging	Material, weight, component type (primary / secondary / transit), packs	To calculate fees and recyclability
Volumes	Quantity placed on a market in a period	The figures that drive fees and thresholds
Business details	Legal entity, company number, registered and operating address	To register and report correctly
Contacts	Named business contacts, including the person responsible for compliance	So filings name the right people
Markets & registrations	The markets you sell into, scheme registration numbers and dates	To track obligations and deadlines
Billing metadata	Plan, subscription status, and a reference to the payment processor	To manage your subscription
Your users	The people you invite, their role, and their access grants	To run your workspace

Uploaded files (import spreadsheets, packaging specs, on-pack artwork) are processed to extract the data above; see Application hardening for how uploads are scanned and handled.

What Oblifee deliberately does not store

Oblifee practises data minimisation - it asks integrations for the least it needs.

• No end-customer personal data. People exist in Oblifee only as your own authenticated users. Your shoppers' names, addresses and contact details are not modelled anywhere.
• No order contents or payment details from your store. Integrations pull product identity and aggregate volumes, not orders, baskets or card data. See Integrations & API.
• No card numbers. Payment card handling is done by the payment processor; Oblifee holds only a reference and the resulting subscription status, never card details.

:::info Least data by design The narrower the data, the smaller the risk. Oblifee's integrations are scoped so that even when they connect to a rich source like a storefront, only the product and volume facts compliance needs cross the boundary. :::

The regulatory brain holds no customer data

The cited rules, fees and thresholds Oblifee reads live in a separate, read-only regulatory brain. Your workspace data is never copied into it, and it holds no information about you or your products - only public regulatory facts and their sources.

Audit trail

Consequential actions are recorded in an audit log: packaging and volume edits, access grants, billing changes, credential lifecycle, exports, and any staff action that touches a workspace. Each entry records who did what and when. The record is written in the same transaction as the change it describes, so the trail can never drift out of step with the data - if a change is rolled back, its audit entry goes with it. Routine interface actions (marking a notification read, switching language) are intentionally left out so the trail stays meaningful.

Data-subject requests

Because Oblifee holds so little third-party personal data, most data-subject requests concern your own team members and your business records, which owners and admins can manage directly in the workspace. Where a connected source sends a data-deletion request (for example a storefront's privacy webhook), Oblifee honours it automatically to keep in step with the source. For anything you cannot action yourself, contact support and we will help.

Retention, at a high level

• Your workspace data persists while your workspace is active, so your history and trends stay intact.
• Uploaded files are transient: an import or packaging spec is parsed and then the file itself is removed - Oblifee keeps the extracted rows, not the document.
• The audit trail is retained as a durable record of consequential actions.
• On closure, your data is removed in line with our contractual and legal obligations. Talk to us if you need a specific retention arrangement.

Where to go next

• Application hardening - how uploads are scanned and how the app is locked down in the browser.
• Tenant isolation - how this data is separated from other workspaces.
• Regulatory brain integrity - why the rules dataset holds none of your data.