Testing the PIA Process Through Release Sampling

Evidence to obtain

• The procedure and the actual trigger criteria (or their absence).
• The complete list of releases and changes in the period, so the sample can be judged against the population.
• PIA records, including who approved, when, and what was decided.
• Traceability from PIA output into requirements, tickets and design decisions.
• The residual-risk acceptance record and the accountable owner.
• Interviews with product owners and engineers about how they know a change needs a PIA.

Conclusions from the sample

• Undefined triggers: a criterion of "high risk" with no criteria cannot be applied consistently by different teams. That is a systemic weakness in the process, not a one-off error.
• Release 11: processing began with no assessment at all. Nonconformity.
• Release 14: an assessment existed before go-live, but if its findings never reached design, the process is producing artefacts rather than controlling change. Conformity turns on the evidence of traceability - check before judging.
• Release 19: assessment signed after deployment means processing started without the control operating. Nonconformity.
• The order of events matters more than the existence of a document; the audit question is whether the assessment influenced the change before it was implemented.

The distinction is about the system, not the paperwork count.

Major indicators present here

• The trigger criteria are absent or meaningless, so the process cannot operate reliably across all 22 releases and beyond.
• Two of three sampled releases had no effective pre-implementation assessment, which suggests the failure is typical rather than exceptional.
• The consequence is unassessed processing of live payment data affecting many PII principals, potentially outside a lawful basis or without adequate safeguards.
• Top management's own monitoring (internal audit, management review) did not detect it.

Minor indicators

• A single release where the assessment exists and operated, but a sign-off is missing, or where a record is incomplete while the process itself works.

Practical test to state in the report: would a major nonconformity arise if you were to look at the next 22 releases? If yes, raise major. A major here also signals that the certification body should not assume the rest of the PIMS operates; widen sampling in change management, supplier onboarding and data subject request handling before concluding.

The claim fails or succeeds on evidence, not on assertion. Ask, and then verify by pulling the actual artefact:

1. "Show me the security risk assessment for Release 11." Then inspect it for: risks to PII principals (as distinct from risks to the company), lawful basis, notice, minimisation, retention, and third-country transfers.
2. "Which fields in your template would record a risk to a customer's patient or payer, and who owns that risk?"
3. "Who decides whether a change needs privacy input, and against what written criterion?"
4. "When the enrichment supplier was added, what did you record about the transfer mechanism and the supplier's own obligations?"
5. "Has a PIA or assessment ever concluded that a change should not proceed? What happened?"
6. "Who accepts residual privacy risk, and where is that acceptance recorded?"
7. "Show me the ticket where a privacy requirement became a design requirement."

If the security template contains no field for risk to PII principals and no one can produce the ticket, the claim is unsupported and the gap is a process gap, not a naming dispute. Record the artefact reference in the working papers so the conclusion is traceable.