Capstone: stand up the program

A DPIA is a written risk assessment you run before a new or changed processing activity that is likely to be high-risk to individuals. It is not paperwork for its own sake - it's the mechanism that forces necessity and proportionality to be argued out loud, on the record, while the design can still change.

The clearest triggers for "high-risk, do a DPIA":

• Profiling or automated decisions that produce significant effects on people - exactly what an AI copilot that scores or predicts consumer behaviour does.
• Large-scale processing of sensitive / special-category data - health notes, financial account info, national IDs.
• Systematic monitoring, new tech whose effects aren't well understood, or combining datasets in ways people wouldn't expect.

Under GDPR the DPIA is an explicit legal requirement (Art. 35) with the DPO advising on it; the PDPC recommends it as good accountability practice. Either way, it's the DPO's default tool for any risky bet.

Walk the five moves against the copilot and watch the risks fall out:

Trace it back to Session 1. GDPR Art. 39 lists the DPO's tasks, and one of them is to advise on and monitor the performance of DPIAs. The DPIA is where the abstract "advise and monitor" duty becomes a concrete, signable artefact.

• You advise, you don't decide. The controller (the business) owns the go/no-go; the DPO advises on risk and mitigations, and that advice goes on the record - including where it wasn't followed.
• It's a living document. A DPIA isn't done at launch; it's revisited when the processing changes - a new data source, a new model version, a new vendor.
• It feeds the evidence stack. Every completed DPIA is a brick in the accountability wall you'll build in Part 2 - proof that risky processing was assessed, not assumed safe.

Keep DPIAs in a register alongside your RoPA. When a regulator asks "how do you handle high-risk processing?", the register is your answer.

The PDPA Accountability Obligation (and GDPR's accountability principle, Art. 5(2)) asks an organisation to take responsibility for the data in its care and to be able to show it. In practice that means having, ready on request:

• Data protection policies and practices - written, in force, and available on request.
• A DPO who is appointed and whose business contact is public - the named, reachable point (Session 1).
• A process to receive and respond to complaints and queries - a real channel, not a black hole.
• Staff who know the policies - communicated internally, with training on record.

"Demonstrate, don't assert" changes how you work day to day. Every governance action should leave a durable artefact behind, filed where you can find it under pressure:

• Decisions get written down - the DPIA sign-off, the consent-model change, the retention schedule - with dates and owners.
• The RoPA is the backbone - your Session 3 record of processing is the single document that answers "what do you hold and why."
• Logs accumulate - the breach register, the DPIA register, the DSAR log, training completions. Boring to keep, priceless when asked.

Evidence goes stale. A policy written last year that nobody follows is worse than no policy - it's documented negligence. Accountability is therefore a cycle, not a one-off build:

An internal audit is just the DPO's "monitor" duty done on a schedule. It's also where you catch drift early - a new data source nobody added to the RoPA, a vendor whose contract lapsed - before a regulator or a breach catches it for you.

The canon narrative is the plan. Each phase maps to sessions you've already done, so the 90 days assemble the course:

• See the data (days 1-30) - build the catalog, RoPA, and classification (Session 3). Until you can name what you hold and why, every other fix is guesswork.
• Stop the bleeding (days 31-60) - the live, headline-making risks: fix consent + purpose + the DNC check before Ilsa's next 8M blast (Session 4), and stand up the breach playbook (Session 5). These stop new harm.
• Build the machine (days 61-90) - the operating model: policies, decision rights, owners / stewards / council, the DPO office (Session 7), plus the lifecycle clean-up (Session 6).
• Govern the AI bet - run the DPIA on the copilot (Part 1), which happens alongside the build, not after it.

A board doesn't want to hear "we breached Section 24 of the PDPA." It wants to hear "here's the exposure in dollars, here's what we've closed, here's what's left, here's what I need." Translate every legal fact into business language:

• Lead with exposure, not statute. "An un-notified breach can cost up to S$1M or 10% of SG turnover, plus the customers we'd lose" beats quoting the section number.
• Show the trend, not the detail. Where were we six months ago, where are we now, on the maturity score (Session 7). Boards move on direction of travel.
• Make the ask concrete. Headcount, budget, or a decision - one slide, three bullets. Never leave the board wondering what you needed from them.

Day 91 is where most programs quietly die - the crisis passed, attention moved on. A live program runs on a small set of metrics reported on a fixed cadence:

Pair the metrics with a cadence: a monthly DPO update, a quarterly risk review with the council, an annual board report and audit. The cadence is what turns a heroic first 90 days into a program that outlives the DPO who started it.