Doc 19 — DPO / Data Subject Request Procedure

1. The Data Protection Officer

1.1 DPW has designated a Data Protection Officer ("DPO") responsible for ensuring DPW's compliance with the Personal Data Protection Act 2012 ("PDPA"), overseeing this procedure, and acting as the contact point for individuals and the Personal Data Protection Commission ("PDPC").

1.2 Contact: dpo@csfile.ai. General privacy enquiries may also be sent to privacy@csfile.ai. Postal: Data Protection Officer, DPW Pte. Ltd., 247B Victoria St, Singapore 188033.

2. Types of request

2.1 You may make any of the following requests:

(a) Access — what personal data about you we have and how it has been used or disclosed in the year before the request (PDPA s 21); (b) Correction — correction of an error or omission in your personal data (PDPA s 22); (c) Consent withdrawal — withdrawal of consent to collection, use or disclosure, on reasonable notice (PDPA s 16); (d) Erasure / deletion — deletion of personal data, subject to the statutory carve-outs in Doc 17 — Document Retention / Records Notice; (e) Marketing opt-out / DNC — opting out of marketing messages on any channel (unsubscribe honoured within 10 days of the request), independent of transactional messages; (f) Complaint — a complaint about how your personal data has been handled (service-level complaints follow Doc 18 — Complaints, Support & Escalation Policy).

3. How to submit a request

3.1 Submit a request: (a) through the client portal (account settings / privacy request function, where available); or (b) by email to the DPO contact in clause 1.2. Include what you are asking for, the personal data or records concerned, and how we can reach you.

3.2 Requests are logged on receipt and handled by or under the supervision of the DPO.

4. Verifying who you are

4.1 We verify a requester's identity before disclosing, correcting or deleting personal data, using checks proportionate to the sensitivity of the request — for example, confirming control of the registered email address or portal account, or asking questions about the account only its holder could answer. A request for someone else's data requires evidence of authority (e.g. a signed authorisation or proof of legal capacity).

4.2 We will never ask for your NRIC/FIN number, or a copy of your NRIC, as a means of authenticating you for a request. NRIC data is collected on the Platform only where the law requires it for regulated services, and it is not used as an authentication credential.

5. Routing: who answers your request

5.1 Personal data on the Platform is held in two capacities (see Doc 04 — Privacy Notice and Doc 05 — Data Processing Addendum, clause 1.2):

(a) Firm-controlled regulated data — client-due-diligence, engagement and case records that a Participating Firm controls as the responsible organisation. If your request concerns this data, DPW does not answer it on the merits: we forward it to the responsible Firm without undue delay and in any event within 5 Business Days (a "Business Day" is a day other than a Saturday, a Sunday or a public holiday in Singapore) (Doc 05 — Data Processing Addendum, clause 5.1), tell you we have done so, and give the Firm the search, export, correction and erasure assistance described in Doc 05 clause 5.2 so it can respond within the PDPA timelines.

(b) DPW-controlled data — account, platform-usage, security, billing and marketing data DPW controls as an organisation. DPW handles these requests itself under this procedure.

5.2 If a request spans both categories, we handle the DPW-controlled part and forward the remainder, and we tell you which part went where.

6. Timelines

6.1 We respond to access and correction requests as soon as reasonably possible. If we cannot respond within 30 days of receiving the request, we will inform you in writing within those 30 days of the soonest time by which we can respond (PDPA ss 21–22 framework).

6.2 Consent withdrawal takes effect on reasonable notice; we will tell you the likely consequences (including that we may be unable to continue providing certain services) before it takes effect.

7. Fees

7.1 Access: we may charge a reasonable fee reflecting the incremental cost of responding. If a fee applies, we will give you a written estimate first and will not proceed until you agree; if the work will exceed the estimate, we give a revised estimate before continuing.

7.2 Correction: no fee.

8. When we may refuse

8.1 We may refuse a request (in whole or part) where the PDPA permits or requires it, including the statutory exceptions to access and correction (for example: opinion data kept solely for evaluative purposes; data subject to legal privilege; where the burden or expense is unreasonable or the request is frivolous or vexatious; where disclosure would reveal personal data about another individual or could threaten safety; or where disclosure is prohibited by law).

8.2 AML/statutory retention carve-out: erasure and some deletion-adjacent requests cannot be actioned for records inside a statutory retention period — in particular CDD/AML records that a Participating Firm must keep for at least 5 years under the Corporate Service Providers Act 2024 (see Doc 17, clause 4). Such records are retained with access restricted to compliance purposes.

8.3 If we refuse any part of a request, we will tell you which part, explain the reason (unless the law prohibits explanation), and inform you of your right to complain to the PDPC (clause 12).

9. Erasure specifics

9.1 Accepted erasure requests are executed per Doc 17: erasable data is deleted or anonymised; statutorily retained data is flagged as restricted and excluded from operational use; you are told what was erased and what was retained and why.

9.2 Where personal data has been disclosed to an external system that we do not control (for example a Third-Party Service Provider performing a completed function, or a Participating Firm's own records), we flag the erasure to that system's operator where we have a contractual route to do so, but we cannot erase records inside another organisation's systems; requests concerning a Firm's records are routed under clause 5.

10. Breach-related requests

10.1 If your request relates to a data breach (for example, you received a breach notification or suspect one), it is escalated to the DPO immediately and handled alongside the incident-response process in Doc 13 — Security / Data-Protection Schedule, clause 7, and the DPA breach provisions (Doc 05, clause 6). We will not use this procedure's ordinary queue to delay breach-related communications required by law.

11. Records of requests

11.1 We keep a log of each request: date received, requester, type, verification performed, routing, response given, timelines met, any fee, and any refusal ground relied on. Request records are retained per the OPERATIONAL class in Doc 17 (or longer where a complaint, dispute or legal hold applies) and are available to the PDPC on lawful request.

12. Escalation to the PDPC

12.1 If you are dissatisfied with our handling of your request, you may complain to the Personal Data Protection Commission (www.pdpc.gov.sg). We will not treat you adversely for doing so. Where the PDPA provides a right of reconsideration or review of a refusal, we will identify it in our refusal response.

13. Review

13.1 The DPO reviews this procedure, the request log and refusal decisions at least annually, and updates this document when the PDPA, PDPC guidance or the Platform's data flows change.