When a request to correct personal data arrives, distinguish a statutory data correction request from an ordinary update. The former must meet the procedural conditions under Hong Kong’s Personal Data (Privacy) Ordinance; the latter still requires practicable steps to keep data accurate for its purpose. Preserve the request and receipt date, assign an owner, and link decisions to evidence and the case record.
How do you identify a correction request?
Do not rely on the email subject or wait for the requester to cite the Ordinance. A statutory request is written in Chinese or English by the data subject or a qualified “relevant person,” asks to correct the subject’s personal data, and concerns a copy previously supplied by the data user in response to a data access request. Verify the earlier request, delivered copy, and fields covered. A record seen in customer service, an investigation, or ordinary correspondence is not enough.
A later email identifying an inaccurate field in that copy may qualify without using the phrase “data correction request.” An oral report is not a statutory written request; no prescribed form is required. A customer simply giving a new address may instead be making an ordinary update, but the organisation must still take practicable steps to maintain accuracy for the data’s purpose.
For example, an employee’s request to change an attendance sheet received during an investigation is an accuracy matter if the copy was not supplied under an access request. Record the earlier request reference and delivery date, disputed field, and change sought. If the case is missing, search sender, attachment, and delivery records; flag anything unverified. Route non-statutory requests separately and record why.
How do you compare the original data and the request?
For each disputed field, record what was supplied, the alleged error, the change sought, and supporting evidence. Compare the exact copy and version, relevant period, source, and purpose. Inaccuracy can include data that is incorrect, misleading, incomplete, or outdated. The requester should provide enough information to identify the alleged error and assess whether the proposed correction is accurate. Disagreement with an outcome alone does not prove an error; differences between documents must be checked against dates and context.
Suppose a copy lists “18 A Street” and the requester says the number should be “81.” Compare the original application, later change records, and effective dates to distinguish a transposed entry from a later move or records from different periods. If material is missing, ask only for what is reasonably needed and explain why; the source may also be checked with a third party. Classify each field as confirmed inaccurate, unclear, or supported as accurate. Do not apply a replacement before verifying it.
| Item | Example | Check |
|---|---|---|
| Copy supplied | 18 A Street | Find copy and date |
| Alleged error | Number should be 81 | Compare original form and source |
| Change sought | Replace 18 with 81 | Check effective date and evidence |
Review one field, period, and claim at a time. Note source document names, dates, and versions. Distinguish inaccurate data from missing information: verify a replacement value, clarify what should be added to a blank field, and check whether outdated data is still used. Preserve conflicting sources and seek reasonable clarification.
How should identity and authority be verified?
Check whether the requester matches the person in the earlier access case and review identity material already held; do not routinely request another identity document. For a request by the data subject, decide whether existing information reasonably confirms identity. For a representative, verify the subject’s identity, their relationship, and authority to make this correction request.
Authorization for an access request does not automatically authorize a correction request. PCPD guidance calls for a separate authorization signed by the data subject for the correction request. Check that the signatory, representative, subject, and scope match. If it covers access only or omits this correction, explain what is missing and request a reasonable supplement. A family member forwarding an employee’s old access copy cannot change the employee’s name solely because they have the email or an older authorization.
The Ordinance specifies when a request must be refused if identity or representative status cannot be established, subject to exceptions. Log checks, evidence, follow-up, dates, and result; restrict access to identity material. Use the least information that can reliably confirm identity, such as a redacted document where sufficient. Store sensitive evidence with restricted access and record its location, not identity numbers, in general case notes. For a spelling correction, the original record, verified account, and earlier delivery record may suffice without unrelated address or bank details.
Who decides the scope of correction?
The data user that understands the purpose and handling should decide, based on records and evidence, whether data is inaccurate and what correction is supported. The requester’s proposal is a claim to check, not an instruction that takes effect automatically. The data user may consult a source, but should not transfer responsibility because a contractor, external party, or another department supplied the data.
Separate facts, opinions, and mixed fields. A misspelled name or transposed date may be checked against an original record; a performance comment may include an opinion that cannot be objectively verified in the same way. If refusing to correct opinion data, the data user must note the disputed matters. No user may use the data without the note, and a copy must accompany the refusal notice. For example, check clock-in times separately from a manager’s comment about work attitude: correct a proven time error and identify the disputed matter in the comment for the note.
If another data user controls handling and limits part of the correction, explain the limitation and complete separable parts where possible; do not reject the whole request on that basis. Record the reviewer, evidence accepted or rejected, changes made, reasons for unchanged items, and location of any note. “Correction” includes amending, erasing, or adding data, so confirm the accuracy of the result and define the fields, periods, and purposes involved. A dispute about a score’s fairness does not decide an entire employment dispute, but verifiable personal data still needs attention. List partial results and reasons precisely.
How should you respond when you cannot make the requested correction?
Distinguish refusal from temporary inability to comply fully. The data user may consider refusing if it is not satisfied that data is inaccurate, lacks enough information to identify the error, cannot be satisfied that the proposed correction is accurate, or another statutory ground applies. Insufficient identity information is covered by separate refusal rules and exceptions. Give a refusal in writing as soon as practicable and no later than 40 calendar days after receipt, with reasons. Include the dispute note when opinion data is involved.
If a large review or source check cannot be completed in time, do not use “in progress” as the response. Before the 40-day period expires, tell the requester in writing why full compliance is not yet possible. Comply as far as practicable, then finish the rest as soon as practicable. If two of three fields are verified and a third awaits a source response, correct the first two and explain why the third remains unconfirmed; do not hold all three.
Keep records of receipt, follow-up, partial corrections, refusal reasons, notices, and completion dates. For a refusal, enter detailed reasons in the required log and retain them for four years. Start the clock at intake: preserve the email, envelope, or system timestamp, and record receipt date, owner, identity follow-up, field status, planned response, and delivery. Match the response to the outcome: corrected with a copy, refused with reasons, or not fully completed within the period with completed parts and reasons. A contractor’s delay does not change the original receipt date.
How do you synchronize affected copies?
A correction is not complete merely because the main screen changed. List affected internal systems, exports, working copies, and processing arrangements; identify who manages each copy still in use and what must change. Preserve before-and-after values, editor, and time so the change is traceable. Once complete, give the requester a copy of the corrected data.
Check disclosure records. If data was disclosed to a third party within the 12 months before correction, and there is no reason to believe the recipient stopped using it for the original or a directly related purpose, the data user must take all practicable steps to provide a corrected copy and written reasons. If data is disclosed after receipt but before a decision, take practicable steps to tell the recipient that correction is being considered.
For a correction to contact information sent to an external provider, check the disclosure date, purpose, and whether the provider still uses it. Record recipient, version, reasons, and delivery result; an internal directory update alone is insufficient. Reconcile affected copies, replies, and case records, and notify only recipients whose copies remain affected. Record the method, date, version, and outcome. If there is reason to believe a recipient stopped using the data for the relevant purpose, record it; 12 months does not require contacting every historical recipient.
For information about Chan & Chung, visit the English-language website.