Data access request process flowchart (request to revocation)

How it works

1. Rename the lanes to your own organisation

   Replace Requester, Data steward, Data owner, Privacy office and Data platform team with the roles you actually have. Keep the data owner separate from the platform team even when the same person does both jobs today, because merging them is what produces a process where the grantor is also the approver. If you have no privacy office, name the person who carries the responsibility rather than deleting the lane, and if stewardship is informal, put the domain lead there and say so in writing.

2. Write your classification scheme into the chart

   "Read the classification and handling rules" is inert until the tiers exist. Name them — public, internal, confidential, restricted, or whatever your scheme uses — and beside each one record what it permits: query in place only, extraction allowed, masking mandatory, signed agreement required. Then say which tier triggers the usage agreement branch and which tier can never leave the analysis environment. Without that table, every request is argued from first principles and the answers drift by approver.

3. Make the purpose statement do real work

   Define the minimum a request has to say: the question being answered, the tables and columns needed, whose records are in scope, how long the access is wanted for, and where any extract will be stored. "For analysis" should be returned rather than approved. This is the cheapest control on the page, because a purpose written properly makes the least-privilege assessment, the masking decision and the expiry date almost mechanical, while a vague one makes all three arbitrary.

4. Set default expiry periods by classification

   Attach a default to "Grant access with an expiry date" for each tier: something like the incident window for break-glass, ninety days for restricted data, six or twelve months for internal data, and the end date of the project where one exists. Let requesters ask for shorter, and make anything longer than the default an explicit decision by the owner. Expiry is the control that survives reorganisations, tool migrations and everybody forgetting the process existed.

5. Agree the emergency route before you need it

   Decide who may invoke break-glass access, what it grants, which account it runs from, how the session is logged, and who is alerted at the moment of the grant. Then set the ratification deadline — a small number of working days — and, more importantly, decide what happens when nobody ratifies. Automatic revocation on the deadline is the only version of this that holds, because a retrospective approval queue with no consequence becomes a permanent backlog within a quarter.

6. Walk it through, then publish a version

   Take the finished chart to a data owner, an analyst who requests access often, the platform engineer who executes the grants and whoever handles privacy, and test it against three real requests from the last quarter, including one that was refused and one that went through break-glass. Correct the diagram to what actually happened rather than what the policy says. Then publish that revision, keep the earlier ones, and link it from the data governance policy so readers know which version they are looking at.

Frequently asked questions

What are the steps in a data access request process?

Raise a request that states the purpose rather than the system; locate the dataset in the catalogue and read its classification and handling rules; confirm it has a named owner, and classify it first if it does not; have that owner assess the purpose against least privilege and decide; where personal data is in scope, record the lawful basis, minimise the fields and take it through a privacy review or a DPIA; offer a masked or aggregated view before raw access; add a signed usage agreement for restricted data; grant the access with an expiry date; enable query logging; record the entitlement in the access register; and then either recertify it before expiry or revoke it, immediately if the person's role or the purpose changes. The steps most often missing in practice are the masked alternative, the expiry date and the revocation trigger on a change of role.

Who should approve access to a dataset — IT or the data owner?

The data owner, meaning the accountable person in the business area the data describes, not the team that operates the platform it sits on. The judgement being made is whether this purpose justifies this data, and only somebody who understands what the records mean can make it. The platform team executes the grant, sets the expiry and turns on the logging; it should not also be deciding who is entitled to read payroll, patient or customer records. A line manager's approval is worth adding as a first gate, because it confirms the request is part of the person's job, but it does not replace the owner's decision. Where a dataset genuinely has no owner, that is a finding in itself, which is why this chart puts "Catalogued with a named owner?" before the assessment rather than after it.

How long should data access last before it expires?

Long enough for the stated purpose and no longer, with the default set by classification rather than negotiated per request. A workable pattern is the duration of the incident for break-glass access, around ninety days for restricted or personal data, six to twelve months for ordinary internal data, and the project end date where the request is tied to a project. The mechanism matters more than the numbers: an expiry date makes removal the default and renewal the deliberate act, so access decays on its own when the process is neglected. Access with no expiry accumulates instead. When you ask an owner to recertify, send the query counts with the request — an entitlement nobody has used in six months is removed without argument, while a list of names with no usage data attached is almost always approved wholesale.

When does a data access request need a DPIA?

Under UK and EU GDPR a data protection impact assessment is required where the processing is likely to result in a high risk to individuals, and it is expected in particular for large-scale processing of special category data, systematic monitoring, and automated decisions with legal or similarly significant effects. Supervisory authorities publish their own lists of operations that always require one. For an internal analytics request, the honest triggers are usually the scale of the population involved, whether the data is special category or criminal-offence data, whether individuals would reasonably expect this use, and whether the output feeds a decision about them. Two things help in practice: screen every personal-data request rather than waiting for someone to raise a concern, and treat the outcome as conditions on the grant — the masked columns, the retention period, the prohibition on re-identification — rather than as a document that is filed and forgotten.

How is this different from a general access request process?

The general access request process at /templates/access-request-process covers systems and applications: somebody needs a role in a business system, a line manager and a system owner approve it, a segregation of duties check runs, and IT provisions it. This page covers datasets, and three things change as a result. The approver is the data owner rather than the system owner, because the question is about the meaning of the records rather than the function of an application. A classification step sits in the middle, because the answer depends on what is in the table. And a masked or aggregated alternative exists, which has no equivalent in application access — you cannot grant somebody sixty per cent of a finance module, but you can grant them a view with the identifiers stripped out. If you are designing a service desk form for application access, start with the general process; if you are governing who can query the warehouse, start here.