In most organisations the same small team handles freedom of information requests and subject access requests. They arrive through the same inbox, they are logged in the same place, and they are frequently tracked with the same fields.
That is convenient and slightly misleading, because the two regimes differ in ways that change how each case has to be run.
Different clocks
FOI runs on 20 working days. Subject access runs on one month under the UK GDPR, extendable by up to two further months where a request is complex or where a number have been received from the same person.
Working days and calendar months diverge quickly, particularly around bank holidays. A system that applies one deadline rule to both will be wrong for one of them, and it will be wrong quietly.
Different starting conditions
An FOI request is applicant-blind: it does not matter who is asking, and the answer is in principle available to anyone. A subject access request is the opposite. It matters a great deal who is asking, because the response contains their personal data.
That introduces an identity verification step with no FOI equivalent, and it means the material gathered cannot simply be published or reused for anyone else.
- FOI answers can be published to a disclosure log. Subject access answers cannot.
- Subject access needs proof of identity before disclosure; FOI does not.
- FOI exemptions come from the Act; subject access exemptions come from the Data Protection Act 2018 schedules.
- A previously answered FOI request may satisfy a new one. No subject access request is ever a duplicate of another person's.
How Phanera helps
Phanera treats each regime separately: its own deadline rule, forms, exemption library, retention period and identity verification requirement. Regimes that only ever release information to the requester can be excluded from the disclosure log and from duplicate checking entirely.
Redaction load is not comparable
FOI redaction is usually a matter of removing personal data from otherwise disclosable records. Subject access frequently inverts that: the material is correspondence about the requester which also mentions other people, and third-party data has to be considered throughout.
That is a slower, more judgement-heavy exercise, and it produces far more individual redaction decisions per case, each of which may need to be justified if the requester challenges the response.
Duplicate detection helps one and not the other
Matching an incoming FOI request against previously answered ones is genuinely useful, and it is the basis of a section 21 response pointing to information already accessible.
Applying the same check to subject access is not merely unhelpful, it is faintly alarming. Nothing a person asks about their own data can already have been published. Regimes need to be able to switch that behaviour off.
Report on them separately
Combining both into a single compliance figure obscures more than it reveals. A team can be comfortably within deadline on FOI and consistently late on subject access, and an aggregate rate will hide it.
Reporting by regime, covering volume, response time and compliance rate for each, makes the actual pressure point visible, which is usually the first step to arguing for the resource to fix it.
