Section 12 of the Personal Data Protection Act 2010 sets out the Access Principle under which individuals can write to Malaysian businesses to ask what personal data it holds about them, and to and to have it corrected where inaccurate, incomplete, or outdated.
These requests must be dealt with properly and within a limited window, but depending on circumstances, can also be lawfully refused under the Act.
To help businesses set compliant policies on dealing with requests, this guide covers:
- what the two rights under section 12 actually are
- how to handle a request step by step
- when a request can properly be refused
- what to do when the data involves other people
Note: For an overview of how this principle sits alongside the other six, see our guide to the 7 principles of Malaysia’s PDPA.
What the Access Principle requires
The mechanics of exercising the Access Principle sit under Section 30 to Section 37 of the PDPA, which deals with how a data access request or correction request is made, what the business must do in response, and the grounds on which it may decline.
In practice this means:
- a request must be made in writing
- the business may charge a prescribed fee for complying with an access request, and
- where access is given, the data must be supplied in an intelligible form
Why access requests usually arrive in a dispute
Understanding the typical context helps a business respond proportionately. In practice, requests most often come from:
- a dismissed employee seeking their personnel file
- a customer with a complaint wanting to see the recording of their interaction
- someone caught on the office CCTV asking for footage after an incident
- a party in a commercial dispute using the access right to obtain material they could not easily get otherwise.
The motive behind a request does not affect the obligation. A business cannot refuse because it suspects the requester is preparing to sue.
What the context does affect is how carefully the response is prepared, and whether legal input is warranted before anything is released.
Handling an access request
1. Recognise it as an access request
Requests rarely arrive labelled as such. An email asking “can you send me everything you have on file about me” is an access request, whether or not it cites the PDPA. Front line staff in HR and customer service should know to escalate rather than answer informally or ignore it.
2. Verify the requester’s identity
Releasing personal data to an impersonator is itself a data breach. Verification should be proportionate: enough to be satisfied the requester is who they claim to be, without demanding so much additional data that verification becomes its own compliance issue. Where a request comes from a lawyer or family member, confirm their authority to act first.
3. Clarify the scope if necessary
A request for “everything you hold” from a ten-year employee can be genuinely large. It is legitimate to ask what they are actually looking for, which usually narrows the exercise and produces a more useful response. This should be genuine clarification, not a delaying tactic.
4. Search thoroughly
Personal data is rarely in one place. A reasonable search covers the CRM, HR systems, email archives, shared drives, work messaging platforms, paper files, and backups where reasonably accessible. This is where a data inventory earns its keep. A business that already knows what it holds can respond in days. One that does not will spend weeks finding out under pressure.
5. Review before release
Check three things: whether it contains other people’s personal data, whether any of it is genuinely exempt, and whether it is intelligible without explanation of internal codes or abbreviations.
6. Respond in writing
State what data is held, provide the copy, and explain anything withheld and on what basis. Keep a record of what was searched, provided, withheld, and why. That record is the evidence the request was handled properly if it is later challenged.
When can a request be refused?
A data controller may refuse where:
- Identity cannot be verified. The business is not satisfied as to who the requester is.
- The request is not sufficiently specific to locate the data, and the requester has declined to clarify.
- Compliance would disclose another individual’s personal data who has not consented, and it is not reasonable to comply without that consent.
- Compliance is not reasonably practicable, having regard to the effort involved relative to the benefit.
- An exemption under the Act applies, such as data processed for the prevention or detection of crime.
Refusal should be the exception and should be explained. A silent or partial response without explanation tends to escalate matters rather than close them. Where a request touches privileged material or relates to an anticipated dispute, take legal advice before responding rather than after.
When the data involves other people
This is the complication that causes the most difficulty in practice. Handing over the whole document is not the answer, and neither is a blanket refusal.
Releasing an entire recording or unredacted thread discloses other people’s data without consent, creating a self-inflicted data breach. Refusing outright ignores the requester’s legitimate right to their own data.
The workable middle ground is usually:
- removing or obscuring other individuals’ identifying information
- seeking consent from the other data subjects where practical
- extracting relevant content about the requester instead of the entire document
Businesses should document the balancing exercise as if the response is later challenged, the reasoning is what they will be judged on.
As CCTV is where this arises most often, see our guide to legally compliant office CCTV in Malaysia for footage requests specifically.
A correction request
Our guide to the PDPA Data Integrity Principle explains how correction requests should be assessed and propagated, but in brief, a business does not have to accept every correction demanded.
Where the data records a fact, inaccuracy should be corrected. Where it records an opinion or assessment, such as a performance rating, the business is generally entitled to maintain the record, though it may be appropriate to note that the individual disputes it.
A practical checklist
- Nominate an owner. Usually the Data Protection Officer, otherwise a named person in HR, legal, or compliance.
- Train front line staff to recognise and escalate. The most common failure is a request sitting unanswered in an inbox because nobody recognised it.
- Maintain a data inventory. Knowing where personal data lives is the single biggest determinant of how quickly a request can be answered.
- Prepare templates for acknowledgement, identity verification, clarification, and response.
- Have a redaction method for documents, and if CCTV is in use, confirm the system can actually blur or crop footage before a request arrives.
- Log every request and what was done with it.
- Know when to escalate to legal, particularly where the request relates to a live dispute, involves privileged material, or where refusal is being considered.
These sit within a broader PDPA compliance framework, with day-to-day ownership resting with the Data Protection Officer where one has been appointed.
PDPA compliance in 90 days
We advise Malaysian businesses on responding to data subject access and correction requests, drafting access and correction procedures, advising on whether material can properly be withheld, and reviewing proposed responses before release where the data involves third parties or potentially privileged material. If you have received a request, or want a process in place before you do, book a consultation with us.
