Data Processing Agreement in Philippines: Template, Key Clauses and Local Law (2026)

What a data processing agreement is, and why it matters in the Philippines A data processing agreement (DPA) governs what one party may do with personal data on behalf of another. The party that decides why and how personal data is processed is, in Philippine law, the personal information controller (PIC). The party that processes it on the controller's instructions, such as a cloud host, a payroll provider, a call centre or a SaaS vendor, is the personal information processor (PIP). The DPA sets the rules between them: the scope of processing, the security required, how a breach is handled, and what happens to the data at the end. In the Philippines this is governed by the Data Privacy Act of 2012 (Republic Act No. 10173), its Implementing Rules and Regulations, and the circulars of the National Privacy Commission (NPC). Because the Philippines is a major outsourcing and business process hub, processor arrangements are common and the rules around them are taken seriously. This page explains what a Philippine DPA should contain. It is general information, not legal advice. ## When do you need a data processing agreement in the Philippines? You need a DPA whenever one organisation handles personal data on behalf of another. Common triggers are using a SaaS vendor that stores customer or employee data, outsourcing payroll, HR or customer support, using a cloud host, or engaging any supplier that will process personal data for you. Under the Data Privacy Act, the controller stays accountable for personal data even when a processor handles it, and the Implementing Rules require that processing by a PIP be governed by a contract or other legal act that binds the processor to the controller. A written DPA is how both the PIC and the PIP meet that requirement and show the NPC they take their duties seriously. ## Key clauses in a Philippine data processing agreement ### Roles and definitions State clearly who is the personal information controller and who is the personal information processor. Use the Act's definitions of personal information, sensitive personal information, processing and data subject. If a party is a controller for some data and a processor for other data, say so. ### Scope and purpose of processing Describe the subject matter, duration, nature and purpose of the processing, the types of personal data and the categories of data subjects. The processor should process only on the controller's documented instructions and for no other purpose. This boundary is the core of the DPA. ### Security measures The Act and its Implementing Rules require organisational, physical and technical security measures to protect personal data. The DPA should require the processor to implement and maintain appropriate measures, such as encryption, access controls, logging, secure disposal and staff confidentiality, in line with NPC guidance, and to keep them current. Both the PIC and the PIP carry security obligations. ### Breach notification The Implementing Rules require notification to the NPC and to affected data subjects within 72 hours of knowledge of a personal data breach that meets the notification criteria (broadly, where sensitive personal information or information that may enable identity fraud is involved and there is a real risk of serious harm). The DPA must require the processor to notify the controller promptly, with enough detail and within enough time for the controller to meet the 72-hour deadline, and to help investigate and remediate. ### Sub-processors Set whether the processor may engage sub-processors, and on what terms. The usual position is prior authorisation (specific or general with notice), that any sub-processor is bound by equivalent terms, and that the processor stays responsible for the sub-processor's acts. ### Data subject rights and assistance The Act gives data subjects rights including information, access, correction, objection, erasure or blocking, and data portability. The processor should help the controller respond to these requests and pass on any request it receives rather than acting on it directly. ### Data sharing versus outsourcing The NPC distinguishes outsourcing or subcontracting (where a PIP processes on the controller's behalf, governed by a processing contract) from data sharing (disclosure to a separate controller, governed by a data sharing agreement under NPC rules). Make sure the DPA fits the actual arrangement, because the two are not interchangeable. ### Data protection officer The Act and NPC rules require organisations to designate a data protection officer or compliance officer for privacy. The DPA can record each party's privacy contact. ### Return or deletion, audit and liability On termination, the processor must return or securely delete the personal data at the controller's choice and confirm it has done so. The controller should have a right to audit or to receive evidence of compliance. Allocate liability and indemnities for data privacy failures clearly and consistently with the main agreement. ## A simple data processing agreement structure 1. Parties, roles (PIC and PIP) and definitions

2. Subject matter, duration, nature and purpose of processing
3. Categories of personal data and data subjects (a schedule)
4. Processor obligations: instructions only, confidentiality, security
5. Breach notification and the 72-hour timeline
6. Sub-processors and flow-down terms
7. Assistance with data subject rights
8. Data protection officer contacts
9. Return or secure deletion of data on termination
10. Audit rights and evidence of compliance
11. Liability, indemnity and governing law (Philippines) ## Common mistakes in Philippine DPAs - Confusing outsourcing with data sharing, and using the wrong form of agreement for the arrangement.

• Using a generic overseas template without checking it against the Data Privacy Act and NPC rules.
• No clear route or timing for the processor to alert the controller, so the controller cannot meet the 72-hour NPC deadline.
• Leaving sub-processing silent, so the controller loses sight of who holds the data.
• No return-or-delete step on exit, leaving personal data with a former supplier. ## Keeping data processing agreements in order Most organisations do not have one DPA. They have a DPA with every vendor that touches personal data, and in an outsourcing-heavy market that can be a long list. The hard part is not drafting the first one. It is keeping them consistent, knowing which suppliers have a current DPA, tracking the sub-processors behind each, and updating terms as NPC guidance develops. That mapping and tracking is the same work whether you have five processors or fifty, and it is far easier when drafting, per-clause risk review, version history and obligation tracking sit in one place rather than across inboxes and folders. A single AI contract workspace such as Adira is built around that idea: draft a DPA, see the risky positions clause by clause, track obligations and renewals, and keep one trusted version. Adira is India-first today, with other jurisdictions including the Philippines on its roadmap, so for Philippine-specific NPC positions you would still confirm the detail with counsel. The point to take is the direction: data agreements you can rely on are the ones that stay in one place, current, with their obligations visible.