How Should Developers Draft Privacy Impact Assessments?

Introduction

Mobile applications and fintech tools commonly process names, contact details, account information, transaction records, identification documents, biometric data, financial information, and other personal information. When an application processes sensitive personal information or creates substantial risks to users, a Privacy Impact Assessment (PIA) should be completed before deployment.

A PIA is not merely a compliance document. It is a structured examination of the application’s data flows, lawful purposes, security controls, risks to data subjects, and measures for reducing those risks. For government systems covered by the E-Governance Act, the PIA is expressly mandatory before the publication or implementation of covered systems. For private developers, fintech companies, banks, and other personal information controllers or processors, the PIA requirement arises from the Data Privacy Act’s accountability and security obligations, as well as relevant National Privacy Commission issuances.

What Is a Privacy Impact Assessment?

A PIA is a process for evaluating and managing the privacy effects of a program, project, procedure, system, technology product, or other processing activity involving personal data. It considers the nature of the information, the data flow, the risks posed by processing, applicable privacy practices, the cost of security measures, and the organization’s size and operational complexity.

The governing legal sources include R.A. No. 10173, or the Data Privacy Act of 2012, its Implementing Rules and Regulations, and NPC Advisory No. 2017-03, Guidelines on Privacy Impact Assessments. NPC Advisory No. 2017-03 states that a PIA should generally be undertaken for every processing system involving personal data, including new and existing systems.

For government systems included in the E-Government Master Plan, Section 10 of R.A. No. 12254, or the E-Governance Act, requires the Department of Information and Communications Technology to conduct a mandatory PIA on proposed systems for processing personal data before publication. The 2026 Implementing Rules and Regulations of R.A. No. 12254 extend the requirement to existing as well as proposed covered systems and require the responsible agency to establish a control framework addressing identified risks.

When Should a PIA Be Completed?

For a new mobile application or fintech tool, the PIA should be completed during planning and requirements gathering, before the application is adopted, used, launched, or made available to the public. Conducting the PIA only after a data breach or after the product has already collected user information defeats its preventive purpose.

A new PIA, or an updated PIA, may also be necessary when an existing application undergoes a material change. Examples include the addition of facial recognition, location tracking, credit scoring, automated decision-making, open banking connections, advertising identifiers, new third-party providers, or cross-border data transfers.

NPC Advisory No. 2017-03 recognizes that a single PIA may cover multiple systems when they involve the same personal data and present similar risks. However, separate or expanded assessments may be appropriate where the applications, users, purposes, data categories, or risk profiles materially differ.

Who Must Prepare the PIA?

The personal information controller (PIC) remains accountable for determining whether the processing is lawful and sufficiently protected. A personal information processor (PIP), software developer, cloud provider, application vendor, or service provider may prepare technical portions of the assessment, but the PIC should review and approve the final PIA.

The assessment should involve the product owner, information technology team, cybersecurity personnel, data protection officer, legal or compliance team, business stakeholders, and representatives responsible for customer support and incident response. Where appropriate, affected stakeholders and civil society representatives may also be consulted.

The Supreme Court has recognized that determining appropriate security measures requires attention to the nature of the personal data, the risks created by processing, the size and complexity of the organization, accepted data protection practices, and the cost of implementation. This approach prevents organizations from applying identical controls to systems with substantially different risk profiles.

What Should the PIA Examine?

A PIA for a mobile application or fintech tool should contain, at minimum, the following components:

• Data inventory: the types and amount of personal data collected, the repositories where the data are stored, the storage media, associated risks, and processing activities throughout the data life cycle;
• Data-flow description: how information is collected, transmitted, accessed, analyzed, shared, retained, archived, and destroyed;
• Purpose and lawful basis: the specific purpose for each processing activity and its corresponding lawful basis;
• Privacy-principles assessment: compliance with transparency, legitimate purpose, and proportionality;
• Risk assessment: the potential effects on the rights and freedoms of data subjects; and
• Security assessment: risks to the confidentiality, integrity, and availability of personal data.

These requirements are reflected in NPC Advisory No. 2017-03, NPC Circular No. 2023-06, and Section 35 of the 2026 Implementing Rules and Regulations of R.A. No. 12254 for covered government systems.

Classify the Information Before Assessing the Risk

The developer should identify whether each data element is personal information, sensitive personal information, or privileged information. Sensitive personal information generally receives greater protection and includes categories such as government-issued identification information, health information, education records, genetic or sexual-life information, and information issued by government agencies that is specific to an individual.

Fintech products should carefully examine whether they process financial information, identification documents, authentication data, credit histories, transaction records, biometric information, or information that may reveal a person’s economic circumstances. The classification affects the lawful basis, security controls, retention period, access restrictions, and incident-response requirements.

Processing sensitive personal information is generally prohibited unless an applicable exception under the Data Privacy Act and its Implementing Rules and Regulations is present. The PIA should identify the specific exception or lawful basis relied upon rather than merely stating that processing is necessary for business operations.

Map the Application’s Data Life Cycle

The PIA should follow the information from collection to disposal. A useful data-flow map should identify:

• the information collected during registration and onboarding;
• the device permissions requested by the application;
• the servers, databases, and cloud environments where data are stored;
• the employees, contractors, affiliates, and service providers with access;
• the disclosures to banks, payment gateways, regulators, law-enforcement agencies, or credit-information providers;
• the use of data for fraud detection, analytics, advertising, or automated decisions; and
• the retention, archival, deletion, and destruction procedures.

The assessment should distinguish information that is necessary from information that is merely convenient to collect. An application should not request access to contacts, calendars, photographs, precise location, microphones, or other device functions unless the permission is relevant, proportionate, and adequately explained.

Establish the Purpose and Lawful Basis

Each processing activity should have a declared and specific purpose. Broad statements such as “for business purposes” or “to improve the user experience” may not adequately explain the processing, particularly where the application uses data for profiling, targeted marketing, credit assessment, or automated fraud analysis.

The PIA should identify whether the processing is based on consent, a legal obligation, protection of vital interests, a public authority function, contractual necessity, or legitimate interest. Where legitimate interest is invoked, the developer should document the interest pursued, the necessity of the processing, and the balancing of that interest against the rights and freedoms of the data subject.

Consent should not be treated as a universal substitute for a proper lawful basis. If consent is used, it should be informed, specific, freely given, and capable of being withdrawn. Optional processing should not be disguised as a condition for receiving a service when it is not necessary for that service.

Assess Privacy and Security Risks

The PIA should evaluate both privacy risks and information-security risks. It should consider accidental disclosure, unauthorized access, identity theft, account takeover, profiling, discrimination, financial loss, reputational harm, surveillance, and the inability of users to exercise their rights.

A fintech application may present a higher risk where it combines identity documents, account credentials, transaction histories, behavioral data, device identifiers, location information, and automated risk scores. The assessment should explain how these data sets interact and whether combining them creates risks not present when each category is considered separately.

The 2026 Implementing Rules and Regulations of R.A. No. 12254 require covered government PIAs to assess risks to the confidentiality, integrity, and availability of personal data, including accidental or unlawful destruction, alteration, disclosure, and other unlawful processing. The same risk-based method is appropriate for private-sector applications operating under the Data Privacy Act.

Design Controls Before Launch

The PIA should not merely describe risks. It should identify specific controls, responsible personnel, implementation dates, and methods for verifying effectiveness.

Relevant controls may include encryption in transit and at rest, strong authentication, multi-factor authentication, role-based access, privileged-access management, secure key management, logging, monitoring, vulnerability scanning, code review, penetration testing, tokenization, data masking, backup protection, segregation of environments, and secure deletion.

NPC Advisory No. 2025-02 requires privacy-by-design and privacy-by-default measures throughout the life cycle of a data-processing system, whether the system is newly developed, operational, or undergoing an update. Examples of privacy-by-default settings include disabled location tracking, private user profiles, unchecked optional consent boxes, unrequired optional fields, and non-retention of payment details unless necessary and authorized.

For systems covered by the E-Governance Act, the 2026 Implementing Rules and Regulations also require testing of privacy and security controls before deployment, testing of privacy notices and data-subject rights mechanisms, code reviews, vulnerability scans, and privacy-architecture reviews.

Prepare Clear Privacy Notices

The application’s privacy notice should describe, in understandable language, the information collected, the purposes of processing, the lawful basis, the recipients or categories of recipients, the retention period, the rights of data subjects, and the manner of contacting the PIC or data protection officer.

Notice should be provided at or before collection, not hidden only in a lengthy terms-of-service agreement. A mobile application should also explain why each permission is requested and whether refusing a permission will prevent the user from accessing the entire service or only a particular optional feature.

For applications using automated credit assessments, fraud scoring, or profiling, the privacy notice should explain the general nature and consequences of the processing to the extent required by applicable law and regulatory guidance. The organization should also provide a channel through which users may raise concerns and exercise their rights.

Control Third-Party and Cloud Providers

The PIA should identify every external party that receives, stores, accesses, or otherwise processes personal data. These may include cloud providers, payment gateways, customer-support platforms, analytics providers, fraud-prevention vendors, identity-verification services, credit-information providers, and advertising platforms.

The contract with each processor should define the processing instructions, security obligations, confidentiality duties, breach-notification procedures, subcontracting restrictions, audit rights, retention limits, assistance with data-subject requests, and return or deletion of data after termination.

A vendor’s certification or security questionnaire should not replace the organization’s own assessment. The PIC should determine whether the provider’s controls are appropriate for the type and volume of data involved and the consequences of unauthorized access.

Address Data Breach and Incident Response

The PIA should contain or reference an incident-response plan. The plan should identify who receives incident reports, who investigates, how affected systems are isolated, how evidence is preserved, how regulators and data subjects are notified when required, and how corrective actions are documented.

Not every security incident automatically requires notification. NPC decisions have recognized that mandatory notification depends on the applicable conditions, including whether personal data were acquired by an unauthorized person and whether the acquisition is likely to create a real risk of serious harm to affected data subjects. The PIA should therefore document the organization’s breach-assessment procedure rather than assume that every incident has the same legal consequence.

Document the Risk Treatment Plan

The final PIA should include a risk register identifying each risk, its likelihood, its potential impact, the existing controls, the proposed mitigation, the responsible owner, and the target completion date. Risks should be classified as accepted, reduced, transferred, or avoided, with written reasons for the decision.

A control framework should take into account the nature of the information, the volume of data, the organization’s size and complexity, current industry practices, the cost of security measures, and the rights and freedoms of data subjects. A low-cost control is not sufficient if it leaves a high-impact risk untreated.

Before launch, management should approve the residual risks. If a material risk cannot be reduced to an acceptable level, the product team should consider changing the design, limiting the data collected, delaying deployment, or abandoning the processing activity.

Common PIA Deficiencies

• Preparing the PIA after launch rather than before implementation;
• describing the application generally without mapping actual data flows;
• collecting excessive information or requesting unnecessary device permissions;
• relying on consent without identifying a lawful and specific purpose;
• omitting vendors, subcontractors, cloud environments, or overseas disclosures;
• listing security controls without testing their effectiveness; and
• failing to assign responsibility for unresolved risks.

Recommended Pre-Launch Checklist

Before releasing a mobile application or fintech tool, the developer and PIC should confirm that:

• all categories of personal and sensitive personal information have been identified;
• the complete data life cycle and data-sharing arrangements have been documented;
• each processing activity has a defined purpose and lawful basis;
• the privacy notice is clear, accessible, and consistent with the actual system;
• unnecessary permissions and excessive data collection have been removed;
• security, privacy, code, and vulnerability testing have been completed;
• data-subject rights can be exercised through a functioning process;
• vendor agreements contain appropriate privacy and security obligations;
• retention and secure-disposal periods have been established; and
• residual risks have been reviewed and approved by the proper decision-makers.

Conclusion

A Privacy Impact Assessment should be treated as a product-design and risk-management instrument, not as a form completed for filing purposes. For applications processing sensitive personal information, the assessment should be completed before launch, updated when the system or legal environment changes, and supported by controls that are tested in actual operation.

Developers and fintech companies should begin with a complete data inventory, identify the lawful purpose and basis for each processing activity, map all disclosures and vendors, assess risks to users, apply privacy-by-design and privacy-by-default measures, and document the treatment of residual risks. The final PIA should be capable of showing not only what the application does, but also why the processing is lawful, proportionate, secure, and respectful of data-subject rights.

About Nicolas and De Vega Law Offices

 Nicolas and de Vega Law Offices is a full-service law firm in the Philippines.  You may visit us at the 16th Flr., Suite 1607 AIC Burgundy Empire Tower, ADB Ave., Ortigas Center, 1605 Pasig City, Metro Manila, Philippines.  You may also call us at +632 84706126, +632 84706130, +632 84016392 or e-mail us at [email protected]. Visit our website https://ndvlaw.com.