Personal Information Protection Impact Assessment (PIPIA) report

Structure (8 sections)

1. 1. 1. Trigger determination and scope

   Art. 55 lists five situations requiring a prior impact assessment and a record of the processing: processing sensitive personal information; using personal information for automated decision-making; entrusting processing to, providing to another processor, or publicly disclosing personal information; providing personal information abroad; and other processing with a significant effect on individuals’ rights. Work through each and record why it is or is not hit; AI companies usually hit several at once, and should cover them in one assessment with separate sections rather than issuing several reports that contradict each other. Scope it to the processing activity and system version: which business line, which model version, which datasets, which stages (collection, training, inference, logging, feedback). The fifth limb is a catch-all, so write down your internal test for it — involving minors, large-scale profiling, or outputs that could affect employment or credit opportunities — so new initiatives can judge for themselves whether it bites.

   Evidence to attach

   • · Determination table across the five limbs (hit or not, reasoning, assessor, date)
   • · Internal test for the catch-all "significant effect" limb
   • · Inventory of business lines, systems and model versions in scope
   • · Relationship to earlier assessments (new / periodic review / change-driven)

   Common pitfalls

   • · Assessing only the sensitive-data limb and omitting automated decision-making and outbound transfer, leaving the report incomplete;
   • · A scope written as "the company’s personal information processing", which maps to no particular system;
   • · No internal test for the catch-all, so nobody judges new initiatives;
   • · An assessment written after launch, where the dates show the "in advance" requirement was missed.

2. 2. 2. Description of the processing activity and data flows

   Art. 56 does not list a "description of processing" element, but without this section none of the three statutory elements can be argued. Write it along the data lifecycle: collection (source, fields, method, whether obtained from a third party) → storage (location, period, encryption and access control) → use and processing (training, labelling, inference, statistical analysis) → transmission and provision (across internal systems, entrusted processing, provision to other processors, public disclosure, transfer abroad) → deletion (triggers, execution, verification). Tag each stage with the categories of personal information and whether they are sensitive (sensitivity may be judged by reference to GB/T 35273-2020), and with the order of magnitude of individuals involved. State the role determination too: at each stage, is the company the processor or an entrusted party, and where processing is joint, what has been agreed. Share one source of truth with the "record of the processing" that Art. 55 also requires, so the two documents cannot diverge.

   Evidence to attach

   • · Data-flow diagram marking the national border, system boundaries and third-party boundaries
   • · Field-level inventory (category, sensitivity, source, retention, order of magnitude of individuals)
   • · Role determination per stage (processor / entrusted party / joint processing)
   • · Entrusted-processing agreements and joint-processing arrangements
   • · Technical description of deletion and sample execution records
   • · The Art. 55 record of processing, drawn from the same source as this section

   Common pitfalls

   • · Mapping only the main business path and omitting logs, analytics events, support tickets and model feedback, which in practice carry a great deal of personal information;
   • · Incomplete identification of sensitive categories (biometrics, location traces, medical and health data, financial accounts, information of minors under fourteen);
   • · A deletion policy with no execution records, so retention limits cannot be shown to be observed;
   • · A wrong role determination: treating the company as an entrusted party for every API call when its use of the input exceeds the entrustment.

3. 3. 3. Lawfulness, legitimacy and necessity of the purpose and method (Art. 56, item 1)

   Item 1 of Art. 56 requires assessment of whether the purpose and method of processing are lawful, legitimate and necessary. Work it in three steps. Lawfulness: map each purpose to a basis in Art. 13 (consent; necessity to conclude or perform a contract, or to conduct human-resources management under lawfully adopted labour rules and a lawfully concluded collective contract; necessity to perform a statutory duty or obligation; necessity to respond to a public health emergency or to protect life, health or property in an emergency; processing within a reasonable scope for news reporting or public-opinion supervision in the public interest; processing within a reasonable scope of personal information the individual has made public or that has otherwise been lawfully disclosed; and other situations prescribed by law or administrative regulation). Where consent is the basis, describe how it is obtained, whether separate consent is required (sensitive personal information, provision to another processor, public disclosure, transfer abroad), and how it can be withdrawn. Legitimacy: is the method proportionate to the purpose, and is consent in substance coerced through pre-ticked boxes, bundled authorisations or repeated pop-ups. Necessity: argue whether the same purpose could be achieved without this personal information, comparing alternatives (de-identified data, synthetic data, a smaller field set, a shorter retention period) and explaining why they were not adopted. In AI the question most often pressed is training necessity: why this model must use raw, individually identifiable data rather than de-identified or aggregated data.

   Evidence to attach

   • · Purpose-to-basis mapping, one row per purpose
   • · Screenshots of the consent interface and consent logs, with separate consent recorded apart from general consent
   • · The withdrawal path and a record of testing it
   • · Necessity analysis with a comparison of alternatives
   • · Field and volume comparison before and after minimisation
   • · Necessity and impact statement for sensitive personal information under Arts. 29 and 30

   Common pitfalls

   • · Relying on "the user accepted the privacy policy" throughout, without separating out the cases requiring separate consent;
   • · Separate consent folded into the same checkbox as general consent, so it cannot be evidenced;
   • · A necessity analysis that argues business benefit and never answers whether de-identified data would do;
   • · A withdrawal path that exists but does not actually stop processing, with nothing said about data already absorbed into a trained model;
   • · No standalone argument of the "specific purpose and sufficient necessity" for sensitive personal information.

4. 4. 4. Impact on individuals’ rights and the security risks (Art. 56, item 2)

   Item 2 of Art. 56 requires assessment of the impact on individuals’ rights and the security risks. Run two lines. The first is impact on individuals, listed from their perspective: discriminatory treatment (differential pricing or service from model bias), constrained autonomy (automated decisions with no human intervention), reputational harm (incorrect personal information in generative output), financial loss (risk-control false positives), physical safety risk (leaked location traces), and weakened rights to be informed and to choose (thin notices, nudging option design). The second is security risk, listed from the threat perspective: leakage, tampering, loss, unlawful acquisition and unlawful use, plus the AI-specific risks — personal information resurfacing in output through training-data memorisation, over-broad retrieval through prompt injection, unauthorised access to vector stores and RAG indexes, model inversion and membership inference, and retention on the third-party model API side. Rate each risk for likelihood and severity and state the basis for the rating (past incidents, test results, industry data). GB/T 39335 supplies a grading method for impact and likelihood; note here which convention you have adopted.

   Evidence to attach

   • · Impact list (consequence, affected group, likelihood, severity)
   • · Security risk register (threat scenario, cause, existing control, residual risk)
   • · Test reports on memorisation, membership inference and prompt injection
   • · Subgroup fairness results where outputs could produce differential treatment
   • · Evidence of the third-party model API’s retention and training-use settings
   • · Statement of the grading convention used for impact and likelihood

   Common pitfalls

   • · Writing "impact on individuals’ rights" as "compliance risk to the company", which inverts the perspective;
   • · A security-risk list of traditional threats only, with no AI-specific risk at all;
   • · Ratings assigned by intuition with no stated basis;
   • · Identifying memorisation risk but running no test, so the conclusion is unsupported;
   • · Not assessing risk on the third-party model API side, taking the vendor’s statement as fact.

5. 5. 5. Lawfulness, effectiveness and proportionality of the protective measures (Art. 56, item 3)

   Item 3 of Art. 56 requires assessment of whether the protective measures are lawful, effective and commensurate with the degree of risk. "Commensurate" means the measures must map one-to-one onto the ratings in section 4: a high-rated risk without a strong control defeats proportionality. Write by category: management measures (the personal information protection officer and management body, internal policies, tiered authorisation, training, vendor management, periodic compliance audits); technical measures (encryption, de-identification and anonymisation, access control and least privilege, audit logging, data-loss prevention, model-side output filtering and memorisation mitigation, permission isolation for vector stores and retrieval); and measures specific to each trigger (separate consent and encrypted storage for sensitive personal information, a non-personalised option and human review for automated decisions, contractual constraints and supervision for entrusted processing, route compliance and supplementary measures for outbound transfers). For each measure state the implementation status (implemented / in progress / planned), how effectiveness is verified, and the latest verification result. Present the measure-to-risk mapping as a matrix so a reviewer can see at a glance whether the high risks are covered.

   Evidence to attach

   • · Measure-to-risk matrix showing whether every high risk carries a strong control
   • · Appointment document for the personal information protection officer and publication of contact details (Art. 52)
   • · Compiled internal policies and training records
   • · Configuration evidence for technical measures (encryption and key management, permission matrix, log retention)
   • · De-identification or anonymisation design and re-identification test results
   • · Evidence of the non-personalised option and the right to refuse for automated decisions (Art. 24)
   • · Compliance audit report under Art. 54 and the compliance audit measures

   Common pitfalls

   • · A long measures list that does not map to the risks, leaving the high-rated items uncovered;
   • · Treating "a policy exists" as proof of effectiveness, with no execution records or verification results;
   • · Claiming anonymisation where only direct identifiers were removed and no re-identification assessment was done — anonymisation and de-identification carry different legal consequences;
   • · Automated decisions offered without a non-personalised option or a convenient way to refuse;
   • · A protection officer appointed but their contact details never published.

6. 6. 6. Dedicated analyses: sensitive personal information, automated decisions and outbound transfers

   Give the three most frequently triggered and most frequently probed situations their own sections rather than burying them. Sensitive personal information: under Arts. 28 to 30, state the specific purpose and sufficient necessity, the strict protective measures adopted, how separate consent was obtained (and, for minors under fourteen, the consent of a parent or other guardian together with dedicated processing rules), and how the individual was informed of the necessity of processing sensitive personal information and its effect on their rights. Automated decision-making: under Art. 24, address transparency and fairness of the outcome, whether unreasonably differential treatment arises in transaction terms such as price, whether a non-personalised option or a convenient means of refusal is offered, and whether, for decisions with a significant effect on the individual, an explanation is provided and the individual may refuse a decision made solely by automated means. Outbound transfer: under Arts. 38 and 39, state the route chosen (security assessment / standard contract / protection certification / another statutory condition), how separate consent was obtained, and how the individual was informed of the recipient’s name, contact details, processing purpose and method, categories of personal information, and the means and procedure for exercising rights under the Law against the overseas recipient. On the standard-contract route, this section should also cover the matters listed in Art. 5 of the Standard Contract Measures, filed together with the contract.

   Evidence to attach

   • · Analysis of the specific purpose and sufficient necessity for sensitive personal information
   • · Separate-consent interface and logs, distinct from general consent
   • · Age-identification mechanism, guardian-consent flow and dedicated processing rules for minors
   • · Transparency text for automated decisions and screenshots of the non-personalised option
   • · Differential-treatment testing report comparing prices and service terms across groups
   • · Transfer-specific notice text and separate-consent logs
   • · Index to the route-compliance materials (security assessment / standard contract filing / certificate)

   Common pitfalls

   • · Outbound separate consent bundled with general acceptance of the privacy policy, so it cannot be evidenced;
   • · A transfer notice that names no recipient or contact details, saying only "an overseas service provider";
   • · Age identification resting entirely on self-declared age with no supporting mechanism;
   • · A "convenient means of refusal" for automated decisions that in fact requires contacting support and waiting days;
   • · Differential treatment declared absent by assertion, with no subgroup comparison data.

7. 7. 7. Conclusion and remediation closure

   The conclusion answers three questions with evidence for each: does the processing have a lawful basis and is the purpose and method legitimate and necessary; are the existing protective measures commensurate with the level of risk; and on what premises does the conclusion hold. Allow three conclusion types: proceed as is; proceed only after specified remediation (listing items, owners, deadlines and acceptance criteria); or do not proceed (with alternatives). Remediation closure is the substance of this section: every item needs completion evidence and a verification record, with the verification matched to the nature of the item (policy items by publication and training records, technical items by configuration screenshots and test results, process items by an operating register). Once remediation is complete, update the conclusion and date the update. Have the personal information protection officer and the business owner sign jointly, and state the review cycle and review triggers for this report.

   Evidence to attach

   • · The conclusion with evidence for each of the three questions
   • · Remediation register (item, owner, deadline, completion evidence, verification, closure date)
   • · Statement of the premises on which the conclusion rests
   • · Signature page for the protection officer and the business owner
   • · Review cycle and triggers

   Common pitfalls

   • · A "proceed" conclusion while remediation is outstanding and the service is already live;
   • · Every remediation item marked complete with no verification evidence;
   • · Signed by legal only, with no business owner, so remediation has no sponsor;
   • · No review cycle, and the report never updated after issue.

8. 8. 8. Three-year retention, processing records and periodic review

   Arts. 55 and 56 require the impact assessment report and the record of the processing to be retained for **at least three years**. Record here: who holds the archive and where, when the retention clock starts (from completion of the assessment or from the end of the processing — take the later, stricter reading), the archive index and how to retrieve items, access rights and confidentiality, and what happens on expiry. The record of processing is not a copy of the report but a continuing record of the actual activity (data flows, recipients, retention periods, material changes), archived alongside the report and kept in step with it. For review, write the triggers as a list: changes in purpose, method or scope; a new data source or a major model version; a new recipient or entrusted party; a change of outbound route; a personal information security incident or a cluster of complaints; updated laws or national standards, such as a new edition of a relevant standard; and findings from a compliance audit. Set a fixed review cycle as well — at least annually — and coordinate it with the periodic compliance audit under Art. 54 so evidence is not gathered twice.

   Evidence to attach

   • · Archive index and retention register (start date, expiry, disposal method)
   • · The record of processing and the mechanism keeping it in step with the report
   • · Archive access rights and confidentiality arrangements
   • · Review trigger list with owners
   • · Records of past reviews and the version history
   • · How this dovetails with the compliance audit plan

   Common pitfalls

   • · The report living on a personal machine or in a chat thread, impossible to produce promptly on inspection;
   • · Reading the three years as "delete after three years" while the processing is still running;
   • · Holding the report but not the record of processing, so one of the two Art. 55 items is missing;
   • · Review triggers that omit model version updates, leaving the report stale across AI product iterations;
   • · Compliance audit and impact assessment collecting evidence separately, consuming business time twice.