A Better PIA Regime, If the Rules Match the Idea
Privacy Impact Assessments have a simple purpose that can easily disappear beneath templates, matrices and compliance requirements. Before…
A Better PIA Regime, If the Rules Match the Idea
Privacy Impact Assessments have a simple purpose that can easily disappear beneath templates, matrices and compliance requirements. Before an organization processes personal data, particularly in ways that could significantly affect people, it should understand what it is doing, why it is doing it, what could go wrong, and what it intends to do about those risks.
The National Privacy Commission’s proposed updated guidelines on Privacy Impact Assessments move the Philippine framework in a generally positive direction. Rather than simply narrowing the current requirement, the draft attempts to create a differentiated regime in which the sensitivity of the data, the nature of the processing and its possible consequences determine when a formal PIA becomes mandatory.
The stakes are higher than an ordinary update to guidance. The draft would supersede NPC Advisory №2017–03 in its entirety and establish the dedicated PIA framework through a Circular with express enforcement consequences, including compliance and cease-and-desist orders, processing bans and fines. PICs and PIPs would have ninety days from effectivity to comply. Precision in the operative provisions is therefore particularly important.
The draft creates several routes into a mandatory PIA. Sensitive personal information is one. A separate and closed category of what the draft calls “high risk data” consists only of financial information, biometric data and personal data relating to children, unless the NPC expands the list through a future issuance. Other triggers depend on the processing itself, including who is affected, how it is carried out and where the data goes. They cover vulnerable groups, automated decision-making and profiling, artificial intelligence and other emerging technologies, behavioral tracking, and certain higher-risk cross-border transfers.
Requiring a PIA whenever sensitive personal information is involved is defensible. Philippine law defines SPI broadly enough to include everyday information such as age, marital status, education, health information and certain government-issued identifiers or records. PIAs will therefore remain common in employment, education, healthcare, financial services and government even under the proposed regime.
There may be a useful effect from that breadth. If using SPI automatically creates an additional assessment obligation, an organization has another reason to ask whether it needs the information in the first place. Sometimes the better privacy control is not stronger encryption or another access restriction. It is deciding that particular information does not need to be collected at all.
The separate high-risk-data category also extends beyond the DPA’s express SPI list. Financial information and biometric data can fall outside the statutory SPI categories, yet the draft treats them as sufficient to trigger a PIA. Because the list is expressly closed, other potentially consequential information, such as precise geolocation, does not enter this category unless another trigger applies or the NPC later expands the list.
Scale is less clear because the provision itself is defectively cross-referenced. Section 4(A)(3) refers to large-scale processing of “data provided in (a) and (b),” even though the preceding subparagraphs are numbered rather than lettered. Read in context, the likely reference is to the preceding SPI and high-risk-data categories. If that reading is correct, ordinary personal information does not require a PIA solely because enormous volumes of it are processed.
That boundary deserves reconsideration. Ordinary personal information can create significant consequences when millions of records are aggregated, retained for long periods or made broadly accessible. The draft already reaches ordinary PI when it is used for profiling, automated decisions, emerging technologies, behavioral tracking or heightened-risk cross-border transfers. Volume alone, however, is not clearly enough.
The proposed regime is therefore better described as a reallocation of assessment effort than a simple reduction in the number of PIAs.
A processing activity outside Section 4’s mandatory categories may be exempt from the formal PIA requirement. It does not become exempt from the DPA and IRR’s underlying risk-based security and data-protection requirements.
Section 20(c) of the DPA requires the appropriate level of security to take into account the nature of the information, the risks represented by the processing, organizational size and complexity, current data privacy best practices and implementation cost. Sections 26(b) and 29 of the IRR reinforce the same underlying approach: data-protection policies and security measures must account for the nature and circumstances of processing and the risks posed to data subjects.
A PIC or PIP outside the formal PIA categories is therefore not released from considering processing risk when determining safeguards and policies. The new Circular can determine when the additional structure of a formal PIA is mandatory. It cannot narrow obligations already imposed by the DPA and its IRR.
Section 4 creates another problem at the boundary of the new regime. It first preserves PIA requirements imposed independently by another law, rule, regulation or issuance, then states that processing outside paragraph A shall not require a PIA. Read literally, the second sentence conflicts with the first.
The practical consequence is concrete. Existing NPC issuances independently require PIAs for CCTV systems and for body-worn cameras and analogous recording devices. A fixed CCTV system without analytics can fall outside the draft’s listed Section 4(A) triggers while remaining subject to the specific CCTV requirement.
The intention is clearly to preserve those independent obligations. The final wording should leave no doubt that they continue.
A differentiated regime inevitably requires someone to decide whether an activity falls within the mandatory categories. The draft recognizes this by defining Threshold Analysis as the preliminary assessment used to determine whether a PIA is required. The NPC Privacy Toolkit, 3rd Edition already contains a sample Threshold Analysis, so the Circular does not need to recreate the methodology.
The more important gap is evidentiary. When an organization conducts a PIA, the assessment itself records what was examined and why. When it concludes that no PIA is required, the draft imposes no equally clear obligation to document and preserve that scoping determination.
Under an enforceable trigger-based framework, a simple requirement would be enough: document the determination and its basis, retain it, and make it available to the NPC when required. A new elaborate form is unnecessary. What is needed is an auditable decision.
The draft appropriately gives the DPO or Compliance Officer for Privacy a significant role, but the operative provisions sometimes blur privacy oversight with ownership. They say that the DPO shall ensure PIAs are undertaken and repeatedly refer to DPO or COP oversight and sign-off.
A DPO usually does not design the HR process being assessed, choose the marketing campaign, determine a system’s operational purpose, decide what information the business needs, or configure the underlying technology. Those facts belong to the people who own the processing.
The DPO should challenge those decisions, evaluate privacy implications, review risks and safeguards, and provide a professional recommendation. Process owners should remain responsible for the operational facts and implementation, while appropriately authorized management makes the decision to proceed and accepts legitimate residual risk.
The Commission’s own Annex already reflects this architecture. The DPO/COP declaration speaks of participation, assessment and professional recommendation, while the form separately provides for Prepared by, Reviewed by and Approved by.
The operative provisions should follow the same structure. A PIA should belong to the processing activity, not to the DPO.
The draft requires annual evaluation of PIAs, but its treatment of material changes is internally inconsistent. Section 4(B) says a PIA shall be required when changes in governing laws, regulations, internal policies or industry practices may affect processing. Section 10(B), however, says a PIC may review a PIA earlier when material changes concern the nature, scope, purpose, context, technologies or personal data involved.
The latter list contains the changes most likely to make an assessment obsolete. If an AI system changes materially, a new purpose is introduced, additional data is collected or a process expands significantly, the original PIA may no longer describe the processing that actually exists.
Circular №2023–06 already requires PIAs to be updated as necessary when significant changes affect the processing. The final Circular should preserve that protection. Material change should trigger reassessment, with annual review serving as the backstop when no significant change occurs.
Several of the draft’s stronger governance safeguards appear in the Annex rather than in the operative text, even though the Circular itself describes the Annex as recommendatory. The pattern appeared earlier in the allocation of PIA responsibilities. It recurs in two further areas: unacceptable residual risk and what happens to findings after the assessment.
The Annex’s illustrative matrix says that processing rated Critical should not proceed until the risk is reduced to an acceptable level. The principle is sound, but the operative text does not establish an equivalent ceiling. It allows risks to be mitigated, avoided, accepted or transferred.
Two boundaries should be explicit. Legal noncompliance cannot become acceptable simply because management approves the risk. Separately, even otherwise lawful processing should reach a point at which residual risk to individuals is too high to justify proceeding.
The Circular need not mandate the Annex’s particular 5x5 matrix. It should, however, place the underlying rule in the operative provisions: processing should not proceed while residual privacy risk remains unacceptable under a documented and defensible methodology.
The Annex also provides fields for required actions, responsible units and completion dates. Those are useful, but the stronger question is what happens after the PIA identifies a problem.
Circular №2023–06 currently requires controls identified through PIAs to be monitored, evaluated, updated and incorporated into the Privacy Management Program. The draft is written to operate notwithstanding Section 4(D), but it does not clearly carry that continuing obligation forward.
If left unresolved, the new framework could become weaker on remediation follow-through. A PIA can correctly identify serious risks and obtain every required signature while still failing as governance if recommendations remain open indefinitely.
Effective follow-through means implementing controls, escalating overdue actions, checking whether mitigation works, revisiting residual risk and, where necessary, changing or abandoning the processing. The final Circular should preserve the connection between PIA findings, continuing control monitoring and the Privacy Management Program.
The draft appropriately considers confidentiality, integrity, availability, threats and vulnerabilities. Those are necessary concerns, but privacy can fail even when security works exactly as designed.
A database may be strongly encrypted while containing information that was never necessary to collect. Access controls may operate correctly while too many people are legitimately authorized to see information they do not need. A system can experience no breach while using information for a purpose that is excessive, unfair or inconsistent with what individuals were told.
Privacy safeguards therefore include cybersecurity controls, but also minimization, purpose limitation, transparency, retention limits, restricted secondary use, human review, process redesign and, sometimes, a decision not to process the information at all. The draft already recognizes many of these concepts. Its risk terminology should consistently reflect them.
The proposed Circular deserves support in principle. Its strongest contribution is the attempt to differentiate why enhanced assessment is required. Sensitive information, specified high-risk data, vulnerable individuals, consequential processing and emerging technologies do not create identical risks, and the framework is stronger for recognizing that.
The remaining issues do not require abandoning the model. They require tighter boundaries and clearer operative rules: preserve evidence when processing is screened out; make clear that DPA and IRR risk obligations continue outside formal PIA scope; preserve independent PIA requirements under other NPC issuances; align process ownership, DPO recommendation and management approval; require reassessment after material change; establish a ceiling for unacceptable residual risk; and carry findings through remediation and the Privacy Management Program. Additional technical drafting issues can be addressed separately in a formal consultation submission without weighing down the broader public discussion.
A PIA should never be valuable simply because an organization can prove that one exists. Its value lies in whether it changes what the organization collects, how it uses information, which risks it accepts, which controls it implements and, occasionally, whether the proposed processing should proceed at all.
The policy direction is sound. The final Circular should make the rules fully reflect it.
Originally published at https://www.linkedin.com.
메타데이터
- post_id
- acfb97eeae32
- slug
- a-better-pia-regime-if-the-rules-match-the-idea-acfb97eeae32
- url
- https://medium.com/@racpablo/a-better-pia-regime-if-the-rules-match-the-idea-acfb97eeae32
- canonical_url
- https://medium.com/@racpablo/a-better-pia-regime-if-the-rules-match-the-idea-acfb97eeae32
- author_url
- https://medium.com/@racpablo
- status
- ok
- fetched_at
- 2026-08-27 04:48:30