POPIA access request

POPIA access request: a practical organisational playbook for South Africa

A POPIA access request is a request by a data subject (after providing adequate proof of identity) asking a responsible party to (i) confirm whether it holds the data subject’s personal information and (ii) provide the record or a description of that personal information—within a reasonable time, in a reasonable manner and format, and in a generally understandable form.

If you handle these requests informally, you risk over-disclosing third-party information, missing deadlines, or generating unnecessary POPIA exposure through sloppy searches, unsecured exports, or avoidable escalation. POPIA also ties the request to PAIA mechanisms and refusal grounds, which means your process must be disciplined and properly documented.

Why a POPIA access request matters for organisations

A POPIA access request is not just an “admin task”. It sits at the intersection of:

• Constitutional rights (privacy and access to information),

• POPIA’s data subject participation rights (sections 23–25), and

• PAIA’s procedural rules and refusal grounds (timeframes, severability/redactions, and specific grounds to refuse disclosure).

Handled properly, the process strengthens trust and reduces disputes. Handled poorly, it can trigger complaints, internal disruption, and in the worst cases a security compromise—where POPIA’s safeguards and notification duties become immediately relevant.

POPIA section 23 access request process: legal foundations in plain language

POPIA section 23 sets the core rule: on adequate proof of identity, the data subject may request confirmation and access to the record/description, including the identity (or categories) of third parties who have had access.

Three legal “bridges” matter in practice:

1. Fees and estimates: POPIA allows a prescribed fee (if any) and requires a written estimate before charging for services to respond, with a potential deposit.

2. Refusal grounds: a responsible party may/must refuse requested information where PAIA’s Chapter 4 refusal grounds apply, and POPIA also cross-references PAIA’s health record provisions.

3. Manner of access: POPIA incorporates PAIA’s request form mechanics (PAIA sections 18 and 53).

In other words: POPIA gives the right; PAIA supplies much of the “how”, the “when”, and the “when you may refuse”.

Step 1: Intake and log the POPIA access request

Treat every POPIA access request as a controlled workflow, not an email thread. At intake:

1. Acknowledge receipt (same day or within 1 business day).

2. Open a case file (ticket number + date/time received + channel).

3. Classify the requester:

   • data subject personally,

   • authorised agent (power of attorney/mandate),

   • parent/guardian, executor, or other capacity.

4. Freeze the scope: capture exactly what was asked for (systems, time period, business unit, transaction, relationship).

5. Assign an owner: typically the Information Officer (or delegated deputy), with Legal/Compliance support.

Good logging is not bureaucracy. It protects you if the requester later alleges delay, obstruction, or selective disclosure.

Step 2: Verify identity for a POPIA access request without over-collecting

POPIA requires “adequate proof of identity”. Your verification should be risk-based and minimal—enough to prevent unauthorised disclosure, not so much that you create a new privacy risk by stockpiling identity documents.

A practical approach:

1. Match the channel to the relationship

   • Employees/customers with a portal login: verify through authenticated portal + a one-time code.

   • Walk-in: verify original ID + record reference number.

   • Email requests: require a signed request plus a verification step (OTP to the cellphone on file).

2. If requesting ID documents, reduce what you keep

   • Ask for a copy with non-essential fields masked (e.g., chip/ID number partially redacted where feasible) and store it inside the restricted case file.

   • Set a retention rule: delete the copy once verification is complete (unless a dispute requires retention).

3. Authority checks for representatives

   • Require written authority and verify the data subject’s consent (or legal authority, e.g., executor appointment).

Identity failures are one of the most common “own goals”: the organisation discloses personal information to the wrong person, which may trigger POPIA’s security and notification obligations if information was unlawfully accessed.

Step 3: Define scope and search strategy across systems

Before anyone searches mailboxes or exports spreadsheets, do a short scoping call (internal) and produce a one-page “Search Plan”:

1. Confirm what “personal information” means in this context

   • HR file, payroll, performance records, CCTV footage, call recordings

   • customer onboarding/KYC

   • support tickets, chat logs

   • marketing preferences

   • metadata (IP logs, device IDs) where linked to the person

2. Confirm the time period and relationship

   • “All records ever” is rarely proportionate; ask the requester to narrow.

   • If you must search broadly, document why.

3. Identify systems of record vs duplicates

   • CRM, HRIS, finance, ticketing, document management, shared drives, backups.

4. Decide what is out of scope (with reasons)

   • Records that do not relate to the requester,

   • purely internal notes not containing their personal information (case-by-case—do not assume),

   • records barred by refusal grounds or privilege (identified later).

5. Set collection rules

   • No forwarding to personal emails.

   • No saving to desktops.

   • Use an access-controlled review folder with audit logs.

This step prevents chaotic searching that creates new copies, new versions, and new leaks.

Step 4: Managing POPIA access request turnaround time and extensions

POPIA requires access within a reasonable time. Because POPIA imports key PAIA machinery, organisations typically align their internal SLA to PAIA’s default decision period:

• Decide and notify within 30 days, with a once-off extension of up to 30 further days if conditions are met (public and private bodies have similar baseline timing mechanics, with private bodies also having “deemed refusal” consequences if no decision is made in time).

A pragmatic “POPIA access request turnaround time” model that reduces friction:

1. Day 0–2: acknowledgement + identity verification request (if needed).

2. Day 3–7: scope confirmation + search plan issued internally.

3. Day 8–20: collection + first-pass review + privilege/third-party flags.

4. Day 21–27: redactions + quality control + draft response letter.

5. By Day 30: decision notice + disclosure pack (or refusal/partial refusal).

If you need more time, send an extension notice early, stating reasons and the new deadline (mirroring PAIA’s approach).

Step 5: Review and apply redactions the right way

Most disputes come from two failures:

• You disclose too much (third-party data, confidential material, privileged content), or

• You redact too much without a defensible legal basis.

The governing principle is partial disclosure where possible: refuse/redact only the protected portion and disclose the rest where severing is reasonably possible.

A disciplined redaction workflow:

1. Convert to a reviewable format (PDF for documents, transcript extracts for calls, still images for CCTV where appropriate).

2. Redact consistently:

   • third-party names, ID numbers, contact details,

   • unrelated individuals appearing in footage,

   • internal credentials, access codes, security configurations.

3. Use a redaction legend:

   • “R1 – third-party privacy”

   • “R2 – confidential commercial info”

   • “R3 – legal privilege”

4. Quality control:

   • ensure redactions are “burned in” (not reversible),

   • check document metadata (authors, tracked changes, comments).

Redaction is not only about compliance; it is a security safeguard. Your access request process must not become the weak point.

Refusing a POPIA access request grounds: when you can lawfully say no

“Refusing a POPIA access request grounds” should never be improvised. POPIA links refusal to PAIA refusal grounds.

Common practical grounds include:

1. Third-party privacy: where disclosure would unreasonably disclose personal information about a third party (subject to exceptions).

2. Third-party commercial information: trade secrets, confidential commercial/technical information supplied in confidence, etc.

3. Confidential information under an agreement: where disclosure would breach a duty of confidence.

4. Safety and security risks: where disclosure could endanger someone’s life/physical safety or compromise security of systems/property.

5. Legal professional privilege: privileged records must be refused unless privilege is waived.

Two caution points:

• Partial refusal is usually required: refuse/redact only the protected portion and disclose the rest.

• Public interest override may apply in limited circumstances (in PAIA terms) where disclosure reveals substantial legal contravention or serious risk and public interest outweighs harm.

Step 6: Drafting the response pack and delivery method

Your response should be designed to (a) satisfy the data subject’s right, and (b) avoid accidental expansion of the dataset.

A safe disclosure pack typically contains:

1. Decision letter (grant / partial grant / refusal) with reasons and legal basis.

2. Index / schedule of documents provided (with redaction codes).

3. Disclosure bundle (documents, transcripts, images) in secure format.

4. Explanation note (plain language summary of systems searched and categories withheld).

5. Correction pathway: remind the data subject of the right to request correction or deletion.

Delivery method should be secure by default:

• encrypted email attachment with password via separate channel,

• secure download link with expiry,

• registered post for physical media only where necessary.

Avoid sending raw exports (CSV dumps, mailbox PSTs) unless you have done a line-by-line review and metadata cleanup.

How to respond to a POPIA access request with minimal compliance risk

If you want a single operational principle for “how to respond to a POPIA access request”: be complete, but not careless.

A structured approach:

1. Be complete

   • Ensure you include the categories you actually hold.

   • If records cannot be found, document what searches were done and why.

2. Be careful

   • Apply refusal grounds where legally justified.

   • Redact third-party data.

   • Confirm privilege with Legal before disclosure.

3. Be consistent

   • Use the same redaction legend across all items.

   • Keep a consistent narrative on scope, systems searched, and timeframes.

4. Be defensible

   • If you refuse or partially refuse, cite the specific ground and explain it without revealing the withheld content.

5. Be secure

   • Keep the review environment locked down.

   • Control exports, encryption, and access rights.

POPIA access request template South Africa: internal workflow + sample wording

Below is a simple internal workflow and template language you can adapt as a “POPIA access request template South Africa”. Ensure your Information Officer has internal measures and systems to process access requests.

A. Simple internal workflow (7 stages)

1. Receive & log (Privacy Office / Information Officer delegate)

2. Identity verification (Privacy Office)

3. Scope & search plan (Privacy + system owners)

4. Collect & preserve (IT + business units)

5. Review & redact (Legal + Privacy)

6. Approval (Information Officer)

7. Respond & close (Privacy Office; archive audit trail)

B. Template language (acknowledgement)

We acknowledge receipt of your POPIA access request dated [date]. Before we can process the request, we require adequate proof of identity to ensure we disclose personal information only to the correct data subject. Please provide [verification method]. Once verification is completed, we will process your request and respond within a reasonable time, having regard to the scope and the records requested.

C. Template language (scope confirmation)

To process your POPIA access request efficiently, please confirm whether your request relates to:
(i) [relationship/category], (ii) the period [dates], and (iii) the following systems/records: [list].
If you would like to narrow or prioritise any categories, please indicate this.

D. Template language (fee estimate where applicable)

In order to respond to your request, we may need to perform search and preparation services. If a fee is payable, we will provide you with a written estimate before incurring any charge and may request a deposit toward that fee.

E. Template language (partial grant with redactions)

We grant your request in part and provide the attached records. Certain portions have been redacted or withheld because they are subject to applicable refusal grounds (for example, protection of third-party personal information and/or legal privilege). Where only part of a record is protected, the remainder has been disclosed.

F. Template language (refusal)

We refuse access to [record/category] because the record falls within an applicable refusal ground under PAIA as incorporated by POPIA. This decision is based on [cite ground in plain language]. We have considered whether partial disclosure is reasonably possible; however, severing the protected information would not leave meaningful content that can be disclosed without undermining the protected interest.

After you respond: corrections, complaints, and audit trail

A mature programme treats the response as the midpoint, not the end.

1. Correction pathway: POPIA gives the data subject the right to request correction/deletion and requires the responsible party to act as soon as reasonably practicable and notify the data subject of action taken.

2. Audit trail: store a defensible record:

   • request + identity proof method,

   • scope confirmation,

   • systems searched,

   • redaction legend and justification,

   • final disclosure bundle hash/checksum (optional but useful),

   • dates to evidence time compliance.

3. Security hygiene: ensure temporary review folders are purged and access rights rolled back; ongoing safeguards require clean closure.

 

FAQ 1: What exactly counts as a POPIA access request?

A POPIA access request is the section 23 mechanism allowing a data subject—after adequate proof of identity—to ask whether you hold their personal information and to obtain the record/description of it, including third-party access categories, within a reasonable time and understandable format.

FAQ 2: Do we have to accept a POPIA access request by email?

There is no single mandatory channel, but you must ensure identity verification and a secure process. Many organisations require the requester to use a standard form (or provide equivalent information) so the organisation can identify the requester, the records, and the preferred manner of access.

FAQ 3: What is the POPIA section 23 access request process in practice?

In practice, the “POPIA section 23 access request process” is: acknowledge → verify identity → confirm scope → search and collect → review and redact → decide (grant/partial/refuse) → disclose securely → document the audit trail.

FAQ 4: What is a reasonable POPIA access request turnaround time?

POPIA states “within a reasonable time”. Many organisations align internal targets to the PAIA-style baseline of 30 days for a decision, with a lawful extension where justified. The safest approach is to commit to 30 days unless complexity justifies a documented extension.

FAQ 5: Can we extend time if the request is very broad?

Yes, where justified. In practice, you should notify the requester early, give reasons, and set a new deadline. Extensions should not be used as delay tactics; they should be linked to volume, consultations, multi-system searches, or similar operational realities.

FAQ 6: Can we charge for handling a POPIA access request?

Potentially yes, depending on prescribed fees (if applicable) and your policy. A cautious approach is to issue a written estimate before charging and to ensure any fee relates to reasonable search and preparation services. Fees should be applied sparingly because they often escalate disputes.

FAQ 7: What are the main refusing a POPIA access request grounds?

Common grounds include third-party privacy, third-party commercial confidentiality, contractual confidence, safety and security risk, and legal professional privilege. Refusal should be narrowly tailored, supported with reasons, and applied only to the protected portion where partial disclosure is feasible.

FAQ 8: Do we have to disclose documents that contain third-party information?

Not in full. The usual approach is redaction: protect third-party personal information and disclose the remainder where severing is reasonably possible. If severing is not reasonably possible, refusal of that record (or portion) may be justified.

FAQ 9: Must we provide “all emails about me” if we have them?

You must perform reasonable searches, but you can ask the requester to narrow timeframes, teams, or topics to make identification and retrieval feasible. Overbroad requests increase the risk of accidental disclosure of third-party information or privileged content.

FAQ 10: Do we have to provide CCTV or call recordings as part of a POPIA access request?

Potentially, if it is personal information about the requester and can be disclosed lawfully and securely. Organisations often provide stills or extracts with appropriate redactions (e.g., blurring bystanders) rather than raw footage.

FAQ 11: What if responding would reveal legally privileged advice?

Privileged material should be withheld unless privilege is waived. Maintain a privilege log internally and provide partial disclosure of non-privileged records where possible.

FAQ 12: What should our “how to respond to a POPIA access request” letter always include?

At minimum:

• the decision (grant/partial/refuse),

• the disclosure format and secure delivery method,

• an index of what was provided,

• redaction/refusal reasons in plain language, and

• the correction/deletion pathway.

References

Useful Links

• Information Regulator (South Africa) — POPIA portal: Official guidance, forms and breach-notification instructions; essential for designing notices and response plans.

• ISO/IEC 24745 — Biometric information protection (overview): International best-practice principles for template protection, storage, and revocation—useful when drafting vendor requirements.

• OWASP Authentication Cheat Sheet: Practitioner guidance to harden authentication systems (rate-limiting, anti-replay, logging) that directly informs biometric deployments. 

If you would like to know more about intellectual property law click here. 

If you would like to know more about protecting your creative works click here.

If you would like to know more about Non-disclosure agreements click here. 

If you would like to know more about Non-circumventions provisions click here. 

If you would like to know more about non-solicitation provisions click here.

If you would like to know more about the CIPC and beneficial shareholding, click here. 

If you would like to have a POPIa compliance checklist check here.

 

Meyer and Partners Attorneys have offices in Centurion and can assist with all of your Family Law, Civil Law, Contractual, and labour-related matters.

This article is a general information sheet and should not be used or relied on as legal or other professional advice. No liability can be accepted for errors, omissions, loss, or damage arising from reliance upon any information herein. Don’t hesitate to contact Meyer and Partners Attorneys Incorporated if you require further information or specific and detailed advice. Errors and omissions excepted (E&OE).