Privacy impact assessment

ISO/IEC 27701 requires you to decide whether a privacy impact assessment (PIA) is needed, and to perform one when appropriate, whenever you plan new processing of PII or change existing processing. Operationalize this by building a trigger-based intake process, clear “PIA required” criteria, a standard PIA template, and a governance path that blocks go-live until risks and mitigations are documented. ¹

Key takeaways:

• Treat PIAs as a change-management gate for new or changed PII processing, not a one-off document.
• Define triggers, owners, and approval steps so projects cannot launch without a completed PIA when required.
• Keep evidence: intake record, decision rationale, completed PIA, mitigation plan, and sign-offs.

A “privacy impact assessment requirement” sounds simple until you try to run it across product, engineering, security, marketing, HR, and procurement at the same time. ISO/IEC 27701 Clause 7.2.5 is short, but it implies a full operating model: someone must detect new or changed PII processing early, decide whether a PIA is needed, run the assessment consistently, and document risk treatment before launch. ¹

For a CCO, privacy lead, or GRC owner, the key is to translate “assess the need for, and implement where appropriate” into repeatable controls: an intake workflow, decision criteria, required fields, required reviewers, and a standard package of evidence an auditor can follow end-to-end. The best PIAs read like practical engineering and operational risk write-ups: what data is processed, why, where it goes, who touches it (including third parties), what could go wrong for individuals, what controls reduce the risk, and what remains unresolved.

This page gives you requirement-level implementation guidance you can deploy quickly and sustain without heroics.

Regulatory text

Requirement (ISO/IEC 27701 Clause 7.2.5 / Annex A.7.2.5): “The organization shall assess the need for, and implement where appropriate, a privacy impact assessment whenever new processing of PII or changes to existing processing is planned.” ¹

What that means for the operator

• You must have a way to identify planned new PII processing and planned changes to existing processing early enough to influence design and controls. ¹
• For each such change, you must make (and document) a decision: PIA not needed vs. PIA needed. ¹
• When appropriate, you must perform the PIA and drive mitigation measures into the project plan before go-live. ¹

Plain-English interpretation

A PIA is your structured check that a new product feature, internal process, analytics initiative, HR system, or third-party arrangement will not create unmanaged privacy risk for individuals. Under ISO/IEC 27701, the control is less about the label “PIA” and more about having a repeatable risk-assessment mechanism that activates whenever PII processing changes, captures privacy impacts, and results in documented risk treatment. ¹

Who it applies to (entity and operational context)

ISO/IEC 27701 frames this requirement for PII Controllers. Practically, this applies when your organization determines why and how PII is processed in:

• Product and platform development (new features, telemetry, identity, personalization)
• Marketing and growth (new audiences, enrichment, ad tech, attribution)
• Customer operations (support tooling, call recording, QA monitoring)
• HR and workplace (screening, benefits, time tracking, performance tooling)
• Data and analytics (new datasets, new joins, new retention, new model training)
• Third party engagements where a third party will collect/process PII on your behalf or you will share PII with them (procurement, partnerships, outsourcing) ¹

If you run a PIMS aligned to ISO/IEC 27701, the exam expectation is that PIAs are embedded into SDLC and change management, not handled informally through email. ¹

What you actually need to do (step-by-step)

1) Define “PII processing change” triggers and route them into intake

Create a short trigger list that maps to how work enters your organization. Common trigger sources:

• Product requirements / engineering tickets
• Architecture review boards
• Security review intake
• Procurement intake for third parties
• Data governance requests (new tables, new pipelines, new access patterns)

Trigger examples you should treat as “planned new or changed processing”:

• New collection of identifiers, precise location, device signals, biometrics, or government IDs
• New purpose for existing data (for example, support data reused for training or analytics)
• New sharing with a third party, new hosting region, or new cross-border transfer pattern
• Material retention change or deletion exceptions
• New automated decisioning that affects individuals

Your control objective: no meaningful PII processing change bypasses the intake funnel. ¹

2) Establish “PIA required” decision criteria and document the decision

ISO/IEC 27701 requires you to assess the need for a PIA each time. Make that assessment consistent by publishing criteria and a decision record.

A practical decision model:

• PIA not required: low-impact changes with no new data types, no new purposes, no new recipients, and no meaningful new risks to individuals. Document rationale anyway.
• PIA required: anything that introduces new data categories, new purposes, new sharing, new technology with novel privacy risk, or meaningful scale/visibility changes.

Evidence tip: Auditors often look for the “negative space,” meaning projects where you decided no PIA was needed. Keep those decisions searchable and linked to the work item. ¹

3) Run the PIA using a standard template (keep it tight, but complete)

Your template should force specificity. Minimum fields that map cleanly to ISO/IEC 27701 intent:

• Processing overview: system, feature, process owner, launch scope
• PII categories, data subjects, sources
• Purpose(s) and expected outcomes
• Data flows: collection → storage → access → sharing → deletion
• Third parties involved (processors/sub-processors), and what they do
• Retention and deletion approach
• Access controls and security measures (high level, but concrete)
• Risks to individuals (privacy harms and failure modes)
• Mitigations: design changes, controls, notices, consent, opt-outs, minimization, logging, monitoring
• Residual risk decision and sign-off (accept, mitigate further, do not proceed)

Keep the PIA readable by engineering and legal. If it becomes a narrative essay, teams will route around it.

4) Put governance behind it: no sign-off, no launch

A PIA is only as strong as the enforcement mechanism. Add a go-live gate:

• Required reviewers: privacy, security, product owner, data owner; add procurement for third party processing changes
• Approval outcomes: approved, approved with required actions, blocked pending changes
• A clear policy: high-risk items cannot ship until mitigations are implemented or formally accepted by the right risk owner (as defined in your governance)

5) Track mitigations to closure and keep the record current

PIAs often fail in operations because mitigations become “future work.” Treat mitigations like control obligations:

• Convert mitigations into tickets with owners
• Link the tickets back to the PIA record
• Require closure evidence (design doc update, configuration screenshot, test result, contract addendum, updated notice)

6) Integrate with third-party risk management and contracting

If a third party is involved, the PIA should point to:

• The specific data shared
• The purpose and limits
• Security expectations and access boundaries
• Any downstream sharing constraints

This is where many programs fragment: the PIA identifies third-party risk, but procurement does not carry it into due diligence and contract terms. Fix that by requiring procurement intake to reference the PIA (or start it).

Operational note: Daydream can act as the system of record tying project intake, third-party due diligence, and PIA artifacts together, so “PIA required” becomes a workflow state with required evidence before approval.

Required evidence and artifacts to retain

Keep these artifacts in a location auditors can navigate without tribal knowledge:

• PIA trigger/intake record (what changed, who requested, when)
• Need assessment decision (PIA required vs. not required) with rationale ¹
• Completed PIA (versioned)
• Data flow diagram or equivalent data map excerpt referenced by the PIA
• Risk register entries (if you maintain one) mapped to PIA risks and residual risk decisions
• Mitigation plan with ownership and closure evidence
• Approvals/sign-offs (names/roles and date)
• Third-party documentation where relevant (due diligence outputs, contract clauses summary, data processing description)

Common exam/audit questions and hangups

Expect these lines of inquiry:

• “Show me how you detect new or changed PII processing before launch.” ¹
• “Give examples where you decided a PIA was not needed and how you documented that decision.” ¹
• “Pick a recent launch and walk from intake → PIA → mitigations → approval → release.”
• “How do third parties get captured in PIAs and how does that connect to due diligence and contracting?”
• “Who can accept residual privacy risk, and where is that authority defined?”

Hangups that cause findings:

• PIAs happen after release, so they cannot influence design.
• PIAs are done for “big projects” only, with no written criteria.
• Mitigations exist only as text in the PIA, with no execution tracking.

Frequent implementation mistakes and how to avoid them

• Mistake: treating the PIA as a checkbox document.
  Fix: require at least one concrete design/control outcome for PIAs that identify non-trivial risk, and track it to closure.
• Mistake: no record of “PIA not required” decisions.
  Fix: log every assessment of need, including negative determinations, in the same intake system.
• Mistake: PIAs don’t cover third parties.
  Fix: add mandatory fields for “PII shared externally,” third-party identity, and purpose limits; block approval if blank.
• Mistake: unclear ownership.
  Fix: assign a PIA owner (usually the product/process owner) and a privacy reviewer; privacy should not be the author for everything.
• Mistake: weak change triggers.
  Fix: connect PIA intake to the systems that teams already must use (security review, procurement request, architecture review, SDLC gates).

Enforcement context and risk implications

ISO/IEC 27701 is a certifiable standard; the practical “enforcement” is usually through internal audit, external certification audits, and customer diligence. The business risk shows up as:

• Shipping features that create privacy risk you cannot later unwind without product disruption
• Inconsistent privacy decisions across teams because there is no recorded rationale
• Third-party data sharing that expands quietly without a clear purpose limitation or oversight trail

If you can produce a clean PIA trail for representative changes, you reduce the likelihood of adverse audit outcomes and shorten customer security/privacy reviews.

Practical execution plan (30/60/90-day)

Day 30: Stand up the minimum viable control

• Publish PIA policy language: triggers, decision requirement, and go-live gating principle tied to new/changed PII processing. ¹
• Deploy a one-page intake form and a decision log (“PIA required?” with rationale).
• Ship a PIA template and define required approvers.

Day 60: Integrate into how work really flows

• Connect intake to SDLC/change management and procurement workflows.
• Train product, engineering, data, HR, and procurement on triggers and what “good” looks like.
• Start mitigation tracking with ticket links and closure evidence.

Day 90: Make it auditable and scalable

• Sample completed PIAs and run an internal quality review (consistency, completeness, mitigation follow-through).
• Tighten criteria based on what teams submitted (common ambiguous cases become explicit triggers).
• Centralize artifacts in a system of record (many teams use Daydream for this) so you can answer audits with a single traceable workflow.

Frequently Asked Questions

What counts as “new processing” under ISO/IEC 27701?

Treat any new collection, new purpose, new sharing, new system, or new use of PII as new processing for intake purposes. If it changes how or why PII is handled, record the assessment of need for a PIA. ¹

Do we need a PIA for every change ticket?

No, but you do need to assess and document whether a PIA is needed whenever new or changed PII processing is planned. Make the assessment lightweight, then escalate to a full PIA when criteria are met. ¹

Who should own the PIA, privacy or the business?

The project’s product/process owner should own completion because they control design and delivery, while privacy provides review and approval. This keeps PIAs tied to implementation, not advisory commentary.

How do PIAs relate to third-party due diligence?

If a third party will receive or process PII, the PIA should define the data shared and the purpose limits, then route that into your third-party risk review and contracting steps. The PIA is where you capture the “why/what”; due diligence validates the “can they do it safely.”

What evidence do auditors usually ask for first?

A recent, real example traced end-to-end: intake trigger, PIA-needed decision, completed PIA, mitigation tickets, and final approvals before go-live. Keep these linked so you can produce them quickly. ¹

What if teams start the PIA too late?

Add a hard gate earlier in the lifecycle (architecture review, security review, procurement intake) so you catch changes before build is complete. Late PIAs usually indicate missing triggers or missing governance.

Footnotes

1. ISO/IEC 27701:2019 Security techniques — Extension to ISO/IEC 27001 and ISO/IEC 27002 for privacy information management