Skip to content

Subject Access Requests

A Subject Access Request (SAR) is a person's right, under Article 15 of the UK GDPR, to be told what personal data you hold about them and to be given a copy of it. You must respond within one calendar month, and in most cases you cannot charge for it.

Badger produces the response pack for you. Every administrator profile page has a Subject Access Request button that renders everything the site holds about that person, laid out for printing or saving as a PDF.

Producing a pack

  1. Go to Users and open the person's profile (/admin/users/{id}).
  2. Click Subject Access Request in the left-hand action panel.
  3. The first time you do this on a site, you are sent to a Confirm data controller details screen instead of the pack — see below.
  4. Click Save as PDF, or use your browser's Print → Save as PDF.
  5. Send the PDF to the data subject through a channel you have verified belongs to them.

The first-time confirmation

A disclosure that doesn't say who holds the data is not a valid Article 15 response, so the pack is gated behind a one-time review. Before the first SAR on a site, Badger shows a form asking you to check and complete:

  • the controller's registered name (prefilled from your Gift Aid organisation name if set),
  • its registered address, and
  • a data protection contact email.

These three are mandatory; everything else on the form is optional. Confirming records who confirmed it and when, and you are not asked again — later requests go straight to the pack. If someone later clears one of the mandatory values, the gate comes back until it is fixed.

You can revisit the form any time at /admin/users/{id}/subjectAccessRequest/controllerDetails, or edit the values under Settings → Configuration.

Verify identity before you disclose

Badger does not verify who asked for the pack — that is your responsibility. Sending someone else's personal data to the wrong person is itself a data breach. Confirm the requester is who they claim to be before sending anything.

What the pack contains

Section What it shows
Who holds this data Your legal entity, registered address, data protection contact and ICO number
About you Name, date of birth, email, phone numbers, account creation date, last active date, sign-up IP address
Approximate location City/country derived from IP, current and historic
Addresses Every distinct delivery and billing address captured on their orders
Orders All orders including incomplete baskets, with line items, status and totals
Subscriptions Product, status, start and cancellation dates, recurring amount
Invoices Invoice number, date, status and total
Card payments Cardholder name, card brand, last 4 digits, expiry, type, issuing country, the anti-fraud check outcomes, and the payment status and amount
Donations Date, campaign, displayed donor name, public message, Gift Aid status, amount
Gift Aid declarations Name, house number, postcode and declaration dates
Saved items Products they liked or saved, with timestamps
Browsing history Pages viewed on the site, with timestamps and browser user agent

The pack is marked Private and confidential in the header, and every printed sheet carries a running header naming the person it concerns, so a page separated from the rest is still identifiable and obviously not for general circulation. The footer repeats the marking with a misdelivery notice.

Every section is present even when empty — it states explicitly that nothing is held, so the response is unambiguous.

Line items are shown by product name rather than SKU id, and addresses are de-duplicated across orders ignoring case and spacing, so the same address typed differently at two checkouts is listed once.

What is deliberately excluded

  • Credentials. Password hashes and remember-me tokens are never printed. They are security material, not information about the person, and disclosing them would be reckless.
  • Internal identifiers. Mongo document ids, Stripe ids and catalogue ids are not shown. They are not the subject's personal data and only confuse the recipient.
  • Card numbers. The platform never holds a full card number — that stays with the payment provider — so there is none to disclose. What is held (brand, last 4, expiry, cardholder name, issuing country) is disclosed in the Card payments section.
  • Card fingerprints. The provider's cross-reference identifier for a card is an internal identifier, meaningless to the recipient, and is not printed.
  • Other tenants. A pack covers one site. Where the same person has an account on another site in the group, that data is a separate disclosure by that site.

Why fraud-check outcomes are included

The address, postcode, security-code and 3-D Secure check results recorded when someone paid are outcomes of checks run against their details, which makes them that person's data. They are disclosed in plain terms ("Postcode: pass") rather than withheld as payment-system internals. The underlying protocol detail — 3-D Secure version and flow — describes the mechanism rather than the person, and is left out.

Why IP addresses and browsing history are included

Both are personal data. An IP address is an online identifier under Recital 30 of the UK GDPR, and a browsing history tied to an identified account is data about that person. Leaving them out would make the disclosure incomplete.

Large browsing histories

Browsing history is capped at the 2,000 most recent page views. When the cap is hit, the pack says so and tells the recipient to ask for the remainder. Supply it separately if they do.

The pack's header and footer are drawn from site configuration under System → Tenants → {site} → Configuration, category legal-entity-config:

Key Purpose
legal-entity-name Registered name of the controller. Required for a valid pack.
legal-entity-company-number Companies House number, if a registered company
legal-entity-vat-number VAT registration number
legal-entity-registered-address Full registered office address, one line
data-controller-contact-email Where data subjects send privacy queries
data-protection-officer Appointed DPO, where one is required
ico-registration-number ICO data protection registration number
privacy-policy-url Link to the published privacy notice

Anything left blank is either omitted from the pack or, for the controller name, address and contact email, flagged in red so you notice before sending.

Details reused from Gift Aid settings

Two facts are already configured under giftaid-config on charity tenants, so the pack reads them from there rather than making you enter the same thing twice:

Shown as Comes from
Data controller legal-entity-name, falling back to giftaid-org-name
Registered charity number giftaid-regulator-number, labelled with giftaid-regulator-name (CCEW / OSCR / CCNI)

A charity that has already set up Gift Aid therefore gets a correctly identified pack with no extra configuration. Set legal-entity-name only when the controller's registered name differs from the name given to HMRC, or on a non-charity tenant where the Gift Aid keys are unset.

Access and traceability

Access is restricted to the ADMIN and SUPERADMIN roles.

Producing a pack writes one line to the application log naming the administrator, the data subject, the site and the number of records disclosed. That is deliberately all it does. The platform does not audit access to personal data generally — the user profile page shows the same orders, donations, addresses and browsing history with no record kept — so a heavier audit trail on this one page would give a false impression of coverage. The disclosure that actually matters is an administrator sending the printed pack to someone, which happens outside the application and cannot be observed by it.

If you need a genuine DSAR register, keep it wherever you already track the request and your response deadline; the log line is a trace, not a register.

The separate confirmation of the data controller details is recorded durably, naming who confirmed them and when, because those details are printed on every future pack.