A Practical Procedure for  Handling Data Subject Access Requests

Data subject access requests (DSARs) are where data protection compliance stops being theoretical. A well-drafted privacy policy and a tidy register of processing activities mean little if an organisation cannot respond competently when an actual individual exercises an actual right. In my Virtual DPO engagements, DSAR handling is consistently the process that exposes whether an organisation’s compliance programme is operational or merely documentary.

The Legal Foundation

Section 34 of the Nigeria Data Protection Act 2023 gives data subjects the right to obtain confirmation of whether their personal data is being processed, access to that data, and information about the purpose, recipients, and retention period of the processing. This sits alongside related rights that often arrive bundled into the same request even when the individual only explicitly names one of them.

The NDPC’s General Application and Implementation Directive reinforces the expectation that data controllers respond within a reasonable timeframe and without undue delay, usually within 30 days. Organisations should not wait for the NDPC to specify an exact number of days before building a defined internal timeline; a defensible compliance posture requires one now.

Step One: Intake and Verification

Every DSAR procedure should start with a single, clearly designated intake point rather than allowing requests to land wherever an employee happens to receive them. A request emailed to a random HR staff member, a customer service line, or even a personal LinkedIn message still counts as a valid DSAR if it clearly expresses intent to exercise a data subject right, regardless of the channel or the specific words used.

Verification is the next critical step, and it is where many organisations either over-collect or under-protect. The standard should be proportionate enough to confirm identity and prevent a third party from fraudulently accessing someone else’s data, without demanding excessive documentation that itself becomes a new processing risk. For an existing employee or customer, matching the request against records already held is usually sufficient; a stranger claiming to be a former customer from years ago may warrant a government ID check.

Step Two: Scoping the Request

Once verified, the request needs to be scoped against the organisation’s actual data holdings. This means identifying every system that may hold the individual’s data. I recommend maintaining a current data inventory precisely so that this step takes hours, not weeks, when a request arrives.

Scoping also means distinguishing personal data about the requester from data about other individuals that happens to appear in the same records.

Step Three: Assessing Exemptions

Not all data within scope must be disclosed. Legitimate exemptions can include data protected by legal privilege, data that would reveal confidential information about a third party without their consent, or data whose disclosure would prejudice an ongoing investigation. Exemptions should be applied narrowly and documented with reasoning. A blanket refusal citing “confidentiality” without specific justification will not withstand scrutiny if the individual escalates to the NDPC.

Step Four: Compiling and Delivering the Response

The response should be structured, not a data dump. Individuals are entitled to understand what is being processed, not just receive a raw export. A well-formed response typically includes a summary of the categories of data held, the purposes of processing, recipients or categories of recipients, retention periods, and the underlying data itself in an accessible format.

Delivery method matters. Sensitive personal data should never be sent over unencrypted email as a matter of convenience; a secure portal or password-protected file with the password communicated separately is a more defensible practice.

Step Five: Logging and Continuous Improvement

Every DSAR, whether fulfilled, partially exempted, or refused, should be logged with the date received, verification method, scope assessed, exemptions applied, and date of response. This log serves two purposes: it is the primary evidence of compliance if the NDPC ever inquires, and it surfaces patterns.

A Note on Internal Readiness

The organisations that struggle most with DSARs are not the ones lacking policy documents but the ones where no single person owns the process end to end, and where the data inventory is aspirational rather than current. Building DSAR readiness before the first request arrives and not after remains the single most cost-effective compliance investment I advise clients to make.