Privacy risk treatment

ISO/IEC 27701 Clause 5.4.1.3 requires you to define and run a repeatable privacy risk treatment process that selects measures to reduce identified PII processing risks to an acceptable level, and to document why each risk is accepted, mitigated, transferred, or avoided. Your goal is audit-ready traceability from risk to decision to implemented controls. ¹

Key takeaways:

• You need a documented, operating process that turns privacy risk findings into treatment decisions and implemented measures.
• Every treatment decision needs a recorded rationale and an “acceptable level” criterion tied to your risk appetite.
• Evidence must connect risk register entries to specific actions, owners, timelines, and verification results.

“Privacy risk treatment” is the step that stops privacy risk management from becoming a reporting exercise. You may already identify privacy risks through PIAs/DPIAs, data mapping, incidents, audits, or third-party assessments. Clause 5.4.1.3 expects you to take the next step: decide what to do about each risk, apply measures, and prove the measures were selected intentionally and implemented. ¹

For a CCO or GRC lead, operationalizing this requirement means you must set clear decision rules (risk acceptance thresholds and approval authority), define treatment options (avoid, mitigate, transfer, accept), and run a workflow that produces consistent artifacts. Auditors will look for consistency: similar risks should receive similar treatment unless you can explain the difference. They will also look for closure: treatment plans should not sit open indefinitely without governance.

If you want speed, build this on top of your existing ISMS risk treatment approach and extend it for PII processing context: data subject impact, lawful basis/contractual requirements, processor/controller roles, retention, and cross-border transfers. ISO 27701 is designed to work that way. ¹

Regulatory text

Requirement (verbatim): “The organization shall define and apply a PII processing risk treatment process to determine appropriate measures for treating identified privacy risks to an acceptable level.” ¹

What the operator must do:

1. Define a privacy (PII processing) risk treatment process that is documented, repeatable, and governed.
2. Apply it to identified privacy risks (from PIAs, risk assessments, incidents, audits, third parties).
3. Determine measures (controls, process changes, contractual terms, technical mitigations) that reduce risk to an acceptable level, and record the decision logic and approvals. ¹

Plain-English interpretation (what “good” looks like)

You maintain a privacy risk register (or integrated enterprise risk register with privacy tags). Each risk has:

• a clear description tied to a specific PII processing activity,
• an initial risk rating,
• a treatment decision (avoid/mitigate/transfer/accept),
• selected measures and an implementation plan,
• an owner and due dates,
• evidence the measures were implemented and validated,
• a residual risk rating and formal acceptance where needed. ²

“Acceptable level” is not a vibe. It is your defined privacy risk criteria: what severity/likelihood combinations can be accepted, who can accept them, and what compensating conditions are required (for example, senior approval for high-impact data subject risks). ¹

Who it applies to

Entity types: PII Controllers and PII Processors. ²

Operational contexts where this becomes real:

• Launching or materially changing products that collect or infer PII.
• Using third parties to process PII (cloud, analytics, payroll, customer support).
• Integrating data sets, expanding retention, or changing purposes.
• Handling sensitive categories of PII or large-scale profiling.
• Responding to incidents where privacy impact is plausible. ²

Controllers need treatment decisions that reflect purpose, transparency, and data subject impact. Processors need treatment decisions that reflect contractual processing limits, security obligations, and subprocessor governance.

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

1) Define the privacy risk treatment process (document + workflow)

Create a procedure that includes:

• Inputs: PIA/DPIA outputs, risk assessments, audits, incident learnings, third-party due diligence findings.
• Treatment options: avoid, mitigate, transfer, accept.
• Decision criteria: risk scoring method; how you define “acceptable level”; triggers for escalation.
• Approval authority: who can accept residual risk at each tier (business owner, privacy lead, CISO, CCO).
• Implementation tracking: owners, tasks, and how closure is verified.
• Exceptions handling: time-bound acceptance, compensating controls, re-review triggers. ²

Practical tip: align the format to your existing ISO 27001 risk treatment plan so evidence is consistent across security + privacy.

2) Normalize risks to “PII processing risks”

Auditors will challenge “IT risks” that are not clearly privacy-relevant. For each privacy risk, ensure the record states:

• the processing activity (what data, whose data, why, where it flows),
• the harm scenario (how a data subject, customer, employee, or partner could be affected),
• the root cause (control gap, process gap, third-party dependency),
• the current controls already in place. ²

3) Choose the treatment path using a consistent decision matrix

Use a lightweight matrix you can defend:

Treatment option	Use when	Typical measures	Required approval
Avoid	Risk is above tolerance and can be removed	Stop processing, change purpose, redesign workflow	Business + privacy leadership
Mitigate	Risk can be reduced to acceptable level	Access controls, minimization, retention limits, monitoring, training	Risk owner + privacy
Transfer	Another party can assume defined obligations	Contract terms, insurance, processor clauses, subprocessor restrictions	Legal/procurement + privacy
Accept	Residual risk meets criteria	Document rationale, time limit, monitoring trigger	Defined risk acceptance authority

Keep “transfer” honest. A contract reduces some exposure; it rarely removes controller accountability. Treat transfer as “risk sharing,” and document what you think you transferred and why. ²

4) Select measures and map them to your PIMS controls

ISO 27701 expects measures to come from your privacy information management system (PIMS) control set, integrated with your ISMS controls. The operational point: link each risk treatment plan item to the control(s) you’re relying on and to the system/process scope where they apply. ²

Example (how to write it in a risk register):

• Risk: “Customer support tool stores chat transcripts containing PII longer than business need.”
• Treatment: Mitigate.
• Measures: enforce retention configuration, implement transcript redaction playbook, add quarterly retention review control, add agent training.
• Residual risk rationale: “Retention aligned to documented purpose; access restricted; review cadence defined.”

5) Implement, verify, and record residual risk

A treatment plan is not complete until you can show it is operating:

• Implementation evidence: configuration screenshots, change tickets, policy updates, training completion records, signed contract addenda.
• Verification evidence: control testing results, internal audit notes, monitoring outputs, sampling results.
• Residual risk rating: updated after controls are in place, with a recorded rationale.
• Formal acceptance (if applicable): signature/approval record, acceptance scope, time window, review trigger. ²

6) Operationalize governance (make it run without heroics)

Set a cadence:

• Intake channel for new privacy risks (PIA gating, incident postmortems, third-party onboarding).
• Regular risk treatment review in a privacy/security risk forum.
• Escalation rules when deadlines slip or residual risk exceeds tolerance. ²

If you need a system to keep traceability tight, Daydream can manage the workflow from risk intake to treatment tasks to evidence collection, and maintain an audit-ready trail that ties each decision to approvers and artifacts.

Required evidence and artifacts to retain

Keep artifacts in a place your audit team can pull quickly, with consistent naming and versioning:

• Documented privacy risk treatment procedure (approved, version controlled). ²
• Risk register entries tied to specific PII processing activities. ²
• Risk treatment plans with owners, actions, and status. ²
• Control mapping from risk to PIMS/ISMS controls. ²
• Risk acceptance records (who accepted, what residual risk, and why it is acceptable). ²
• Validation/testing evidence demonstrating measures work as intended. ²

Common exam/audit questions and hangups

Expect these and prepare clean answers:

• “Show me one privacy risk from identification through closure. Where is the evidence?” ²
• “How do you define ‘acceptable level’ for privacy risk, and who approves exceptions?” ²
• “How do you ensure treatment plans are completed and not left open?” ²
• “How do processor risks and controller risks differ in your methodology?” ²
• “How do you select measures, and how do you know they reduce privacy risk?” ²

Hangup you’ll see in practice: teams can describe controls, but cannot show the decision trail from a specific privacy risk to why those controls were chosen.

Frequent implementation mistakes (and how to avoid them)

1. Treating privacy risk treatment as security-only remediation.
   Fix: require each risk to state the PII processing context and data subject impact, not only CIA impact. ²

2. Accepting risk without defined acceptance criteria.
   Fix: publish privacy risk acceptance thresholds and approval authority in the procedure, then enforce them in workflow. ²

3. “Transfer” as a loophole.
   Fix: document exactly what contractual measures exist and what residual obligations remain with you as controller/processor. ²

4. No proof the measures operate.
   Fix: add a verification step to every treatment plan, and require evidence before closure. ²

5. Risk registers that do not tie to systems and owners.
   Fix: require system/application owner, process owner, and a privacy accountable party for each record. ²

Execution plan (30/60/90-day)

First 30 days (Immediate)

• Draft and approve the privacy risk treatment procedure (inputs, options, acceptance criteria, approvals, evidence). ²
• Define “acceptable level” criteria and who can accept residual risk. ²
• Stand up a single register view for privacy risks and treatment status (spreadsheet is fine short-term if governed). ²

Days 31–60 (Near-term)

• Triage top privacy risks already known (from PIAs, incidents, audits, third parties) and assign treatment decisions, owners, and measures. ²
• Build control mapping so each treatment points to a control objective/control in your PIMS/ISMS library. ²
• Add a verification step and closure criteria; stop closing items without evidence. ²

Days 61–90 (Operationalize)

• Run the process through at least one full governance cycle: review open items, escalate overdue actions, record residual risk acceptance where needed. ²
• Audit your own trail: pick samples and confirm you can show end-to-end traceability in minutes, not days. ²
• If the spreadsheet is straining, move the workflow to a system like Daydream to centralize tasks, approvals, and evidence with clean audit exports.

Frequently Asked Questions

Do we need a separate privacy risk treatment process from our ISO 27001 risk treatment?

Not necessarily. The requirement is that you define and apply a PII processing risk treatment process, which can be an extension of your existing risk treatment method if it explicitly covers privacy risk context and produces the required records. ²

What does “acceptable level” mean in practice?

It means you predefine privacy risk criteria and who can accept residual risk at each level. An auditor will expect to see those criteria applied consistently and reflected in acceptance records. ²

Can we accept high privacy risks if the business insists?

You can accept risks only under your documented acceptance criteria and approval authority. If your process allows acceptance above a threshold, document the rationale, compensating measures, and governance conditions clearly. ²

What’s the minimum evidence set an auditor will ask for?

A documented process, a set of privacy risks with treatment decisions, and proof that selected measures were implemented and validated. The evidence must connect risk identification to treatment to residual risk. ²

How should processors handle privacy risk treatment if the controller defines the purposes?

Processors still need a treatment process for risks arising from their processing activities and obligations. Treatment measures often focus on contractual controls, technical and organizational measures, and subprocessor governance. ²

How do we keep third-party privacy risks from getting stuck in procurement?

Require a treatment decision for every third-party privacy risk: mitigate through contract/security measures, transfer through defined terms, avoid by selecting another provider, or accept with recorded approval. Track actions and evidence like any other treatment plan. ²

Footnotes

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

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