Privacy Risk Assessment for ISO 27701 and GDPR
The Monday morning meeting felt familiar to Maria, the CISO of a fast-growing health-tech firm.
The CEO wanted a simple dashboard showing GDPR risk exposure before the company launched its AI-driven patient analytics platform. The new Privacy Lead, David, had a 50-tab Record of Processing Activities, or RoPA. Engineering had secured the cloud environment. Product was ready to release. The vendor described its subprocessor stack as “enterprise grade.”
But one question stopped the room.
“What is our actual risk, and can we prove to enterprise clients that we have it under control?”
The RoPA showed what the company processed. The security risk register showed infrastructure risks. A few DPIAs lived in separate documents. Supplier reviews sat in procurement folders. Nobody could show one traceable decision chain from processing activity to privacy risk, DPIA decision, treatment plan, control mapping, residual risk approval, and review date.
That is the gap many organizations face when moving toward ISO/IEC 27701:2025 and GDPR accountability. They have privacy notices, vendor questionnaires, RoPA entries, data maps, DPIA templates, and ISO/IEC 27001:2022 controls. What they often lack is the operating layer that connects them.
A mature Privacy Information Management System, or PIMS, does not treat privacy risk assessment as a legal side document. It treats it as a repeatable decision workflow: identify processing, screen risk, decide whether a DPIA is needed, select controls, assign owners, approve residual risk, monitor triggers, and retain evidence.
That is where Clarysec’s policy packs, Zenith Blueprint, and Zenith Controls help teams move from disconnected spreadsheets to a defensible privacy risk engine.
Privacy risk assessment is the missing operating layer
GDPR accountability is often reduced to “having documentation.” Documentation matters, but Article 5(2) goes further. The controller is responsible for, and must be able to demonstrate, compliance with the principles in Article 5(1), including lawfulness, fairness, transparency, purpose limitation, data minimisation, accuracy, storage limitation, integrity, and confidentiality.
That requires more than a RoPA. The organization must be able to explain why a processing activity is acceptable, what risks it creates for individuals, which controls reduce those risks, who owns the decision, and when it must be reviewed.
ISO/IEC 27701:2025 strengthens this expectation by embedding privacy governance into a managed PIMS. In practice, privacy risk assessment must connect six operational objects:
- The PII processing inventory or RoPA.
- Lawful basis and purpose documentation.
- Privacy risk screening and DPIA decisioning.
- Risk treatment and control selection.
- Supplier, processor, and subprocessor governance.
- Evidence retained in the ISMS and PIMS.
Clarysec makes that connection explicit. In the Enterprise Privacy Risk Assessment and DPIA Policy, the trigger happens before processing begins:
[Both] The Process Owner / Business Owner MUST initiate privacy risk screening in REG04 before new or materially changed PII processing recorded in REG02 begins.
The same upstream discipline appears in the Enterprise PII Processing Inventory and Lawful Basis Policy:
[Both] The Process Owner / Business Owner MUST initiate privacy risk and DPIA screening in REG04 before new or materially changed PII processing proceeds.
This prevents the common failure pattern: the product launches, the RoPA is updated later, the DPIA question arrives too late, and the risk register never receives the privacy scenario.
For controllers, this supports GDPR Article 6 lawful basis discipline, Article 25 data protection by design and by default, Article 32 security of processing, and Article 5 accountability. For processors, it supports documented instructions, customer assurance, contract boundaries, and subprocessor transparency.
Start with processing reality, not a blank template
A privacy risk assessment fails when it begins with an empty form and no operational context. The first question should not be “Do we need a DPIA?” It should be “What processing is actually changing?”
For a SaaS, fintech, or health-tech organization, the change may involve:
- A new data category, such as behavioural usage data, health data, biometric signals, or payment metadata.
- A new purpose, such as fraud scoring, patient analytics, AI-assisted support, churn prediction, or personalization.
- A new recipient, processor, or subprocessor.
- A new support workflow or cross-border access path.
- A new retention period.
- A new model, algorithm, or automated recommendation.
- A new data subject group, such as minors, employees, patients, or financially vulnerable individuals.
GDPR’s definitions are broad. Personal data includes identifiers, online identifiers, location data, and factors linked to identity. Processing includes collection, storage, retrieval, use, disclosure, restriction, erasure, and destruction. A personal data breach includes accidental or unlawful destruction, loss, alteration, unauthorized disclosure, or access.
That means a privacy risk workflow must capture more than whether the database is encrypted. It must capture why processing exists, whether the purpose is compatible, whether the lawful basis is valid, whether special-category data is involved, whether individuals can understand the processing, and whether safeguards are proportionate.
For smaller teams, the SME Data Protection and Privacy Policy provides the starting point in clause 5.2.1:
The Privacy Coordinator must maintain a register of all personal data processing activities, including data categories, purpose, lawful basis, and retention periods
That register is not paperwork. It is the input model for privacy risk assessment. Without data categories, purpose, lawful basis, and retention periods, the assessment cannot reliably evaluate purpose limitation, data minimisation, storage limitation, transparency, or fairness.
The same SME policy also makes risk review a recurring obligation in clause 7.1.1:
The Privacy Coordinator must assess privacy risks annually and during major system changes
For enterprises, the governance cadence is stronger. The Enterprise Data Protection and Privacy Policy states:
Privacy risk registers shall be maintained within the ISMS and reviewed at least quarterly by the Data Protection Officer (DPO) and CISO.
This is where ISO/IEC 27701:2025 and ISO/IEC 27001:2022 integration becomes practical. Privacy risks are not buried in legal folders. They are reviewed alongside security risks, supplier risks, incidents, audit findings, treatment plans, and management reporting.
The Clarysec REG02 to REG04 workflow
The most effective privacy risk assessment process is simple enough for business owners and rigorous enough for auditors. Clarysec’s model uses REG02 as the PII processing inventory and REG04 as the privacy risk assessment and DPIA record.
| Workflow point | Practical question | Evidence created | Owner |
|---|---|---|---|
| REG02 processing entry | What PII is processed, for what purpose, by whom, and under which lawful basis? | Processing inventory record, lawful basis, data categories, retention period | Process Owner |
| REG04 screening | Does the activity create elevated risk to individuals or trigger DPIA criteria? | Privacy screening decision, rationale, review date | Privacy Lead or PIMS Manager |
| DPIA decision | Is a full DPIA required before processing begins or changes? | DPIA record or documented no-DPIA rationale | DPO or Privacy Lead |
| Risk treatment | Which controls reduce the risk to an acceptable level? | Treatment plan, control mapping, due dates | Risk Owner |
| Residual risk approval | Who accepts remaining high risk, and under what conditions? | Approval record, acceptance rationale | Top Management where required |
| Review trigger | What changes reopen the assessment? | Review date, change triggers, monitoring evidence | Process Owner and Privacy Lead |
The Privacy Risk Assessment and DPIA Policy defines the minimum evidence needed before REG04 can be closed:
[Both] The Privacy Lead / PIMS Manager MUST ensure that each REG04 assessment records risk rating, treatment decision, owner, due date, residual risk, approval status, and review date before closure.
That sentence is the operating backbone. A privacy risk assessment is not closed because someone wrote “low risk” in a comment box. It is closed when the record includes the rating, treatment decision, owner, due date, residual risk, approval status, and review date.
For SMEs, the same discipline is scaled down. The SME Risk Management Policy states:
Each risk entry must include: description, likelihood, impact, score, owner, and treatment plan.
The principle is proportionality, not informality. Smaller organizations may use a simpler register, but every risk still needs a description, score, owner, and treatment plan.
Use the ISO/IEC 27001:2022 risk engine for privacy
Privacy risk should not live outside the organization’s risk management method. ISO/IEC 27001:2022 already provides the management-system engine: context, interested parties, scope, leadership, risk assessment, treatment, operational control, documented information, performance evaluation, and continual improvement.
Clauses 4.1 to 4.4 require the organization to understand internal and external issues, interested-party requirements, ISMS scope, and ISMS processes. For privacy, interested parties include customers, data subjects, employees, regulators, processors, subprocessors, supervisory authorities, financial-sector supervisors where relevant, and contractual customers.
Clause 6.1.2 requires an information security risk assessment process. Clause 6.1.3 requires information security risk treatment, including selecting controls, producing a Statement of Applicability, formulating a risk treatment plan, and obtaining risk owner approval of the plan and residual risks. Clauses 8.2 and 8.3 require performing information security risk assessments and treatments at planned intervals or when significant changes occur, while retaining documented results.
Clarysec’s Enterprise Risk Management Policy aligns with that structure in clause 5.1:
A formal risk management process shall be maintained in accordance with ISO/IEC 27005 and ISO 31000, covering risk identification, analysis, evaluation, treatment, monitoring, and communication.
For privacy, the risk criteria must include impact to individuals, not only business impact. A low financial loss can still be a high privacy impact if the processing involves special-category data, vulnerable individuals, profiling, opacity, unlawful retention, inability to exercise rights, or non-material harm.
Clarysec’s Zenith Blueprint: An Auditor’s 30-Step Roadmap explains this in the Risk Management phase, Step 10:
When defining impact, it’s wise to relate levels to your specific business scale. For example, “Major financial impact = loss > $100k” (adjust to your context). Also consider regulatory impact : for example, a data breach of personal data might automatically be “Major” or “Severe” due to GDPR fines and notification requirements, even if the direct financial loss is unclear.
That guidance is especially important for AI analytics, health data, financial profiling, employee monitoring, and customer scoring. The harm may be legal, reputational, discriminatory, operational, contractual, or personal.
A practical example: AI patient analytics
Return to Maria and David. Their health-tech platform will process special category health data under GDPR Article 9. It will use patient history, appointment data, clinician notes, and model outputs to generate risk insights.
Using Zenith Blueprint, they begin with Step 9, identifying assets, threats, and vulnerabilities:
For each asset, record key details: Name/Description, Owner, Location, and Classification (sensitivity). For example, an asset could be “Customer Database – owned by IT Dept – hosted on AWS – contains personal and financial data (High sensitivity).”
The same step adds the privacy lens:
Ensure personal data assets are flagged (for GDPR relevance) and critical service assets are noted (for potential NIS2 applicability if you’re in a regulated sector).
Maria’s team identifies the AI Patient Analytics Platform, patient database, data warehouse, model training pipeline, clinician dashboard, cloud storage, identity provider, audit logs, support ticket platform, and third-party analytics tool. Each asset gets an owner, location, classification, and PII relationship.
They then define risk scenarios. One is unauthorized access to health records. Another is accidental disclosure through analytics exports. A third is AI model bias caused by skewed training data, resulting in unfair or discriminatory patient risk scoring.
Step 11 of Zenith Blueprint explains the role of the risk register:
The Risk Register is typically a spreadsheet (our template “Risk Register and SoA Builder.xlsx” has a dedicated sheet for this). It serves as the master log of risks.
A privacy risk entry for the AI model bias scenario may look like this:
| Field | Entry | Clarysec reference |
|---|---|---|
| Risk ID | PRV-004 | Zenith Blueprint, Step 11 |
| Asset | AI Patient Analytics Platform | Zenith Blueprint, Step 9 |
| Threat | AI model bias from skewed training data | Zenith Blueprint, Step 9 |
| Vulnerability | Lack of formal model validation and fairness testing | Zenith Blueprint, Step 9 |
| Risk description | The model could produce discriminatory patient risk scores, leading to unfair treatment and infringement of data subject rights | Risk Management Policy SME, clause 5.1.2 |
| Likelihood | Likely, 4 of 5 | Zenith Blueprint, Step 10 |
| Impact | Major, 4 of 5, due to special category data and potential harm to individuals | Zenith Blueprint, Step 10 |
| Risk score | 16, High | Zenith Blueprint, Step 10 |
| Risk owner | Head of Data Science | Zenith Blueprint, Step 11 |
| Treatment plan | Implement model validation, fairness testing, representative retraining, explainability review, DPO review, and DPIA completion | Risk Management Policy SME, clause 5.1.2 |
This entry does what the old spreadsheet could not. It connects a processing activity to an asset, threat, vulnerability, risk to individuals, owner, score, treatment plan, and evidence trail.
Because the processing is high risk and involves special-category data, the DPIA is not a separate afterthought. It becomes the deeper assessment stage for a risk already logged in the system. The Enterprise Data Protection and Privacy Policy states:
All significant changes to systems or processes involving personal information (PII) shall require a documented Data Protection Impact Assessment (DPIA), reviewed by the Data Protection Officer (DPO).
For high residual controller risk, the Privacy Risk Assessment and DPIA Policy adds:
[Controller] Top Management MUST approve high residual privacy risk acceptance in REG04 before high-risk controller processing begins or continues.
The launch decision now has traceability: what changed, what was assessed, what risks were identified, what controls were selected, who owns the treatment, who approved residual risk, and when the decision will be reviewed.
From risks to controls with Zenith Controls
Privacy risk assessment only matters if it leads to control decisions. Clarysec’s Zenith Controls: The Cross-Compliance Guide is the cross-compliance guide that maps ISO/IEC 27001:2022 and ISO/IEC 27002:2022 controls to related requirements across frameworks. It is not a separate set of controls. It helps teams understand how control evidence supports multiple obligations.
For privacy risk assessment, Zenith Controls highlights three central ISO/IEC 27002:2022 controls:
| ISO/IEC 27002:2022 control | Why it matters for privacy risk assessment | Example evidence |
|---|---|---|
| 5.34 Privacy and protection of PII | Anchors privacy governance, legal requirements, data subject protection, and safeguards | PIMS procedures, DPIA records, PII handling rules, privacy notices |
| 5.9 Inventory of information and other associated assets | Ensures the organization knows which information assets exist, who owns them, where they are, and how sensitive they are | Asset inventory, RoPA references, classification records |
| 5.19 Information security in supplier relationships | Extends privacy risk into processors, subprocessors, cloud platforms, analytics vendors, and support providers | Supplier assessments, contracts, monitoring records, exit plans |
Control 5.34 also supports GDPR Article 25 and Article 32, NIS2 Article 21 cybersecurity risk-management measures, DORA ICT risk management expectations, and NIST CSF 2.0 outcomes such as GV.OC-03 for legal, regulatory, contractual, privacy, and civil liberties obligations, plus PR.DS-01 for protecting data at rest.
Step 13 of Zenith Blueprint connects these decisions to the Statement of Applicability:
Cross-reference regulations: If certain controls are implemented specifically to comply with GDPR, NIS2, or DORA, you can note that in either the Risk Register (as part of risk impact justification) or in the SoA notes.
This is how a privacy finding becomes an ISMS and PIMS control decision, not just a legal comment.
Supplier and processor risk must be assessed before approval
Many privacy failures start in vendor governance. A processor adds a new subprocessor. A support vendor gains production access. An analytics platform stores event data in a new region. Procurement signs the contract before privacy sees the risk.
Clarysec’s Enterprise Processor, Subprocessor and Third-Party Privacy Management Policy prevents that by connecting supplier review, REG04, and the third-party register:
[Both] The Privacy Lead / PIMS Manager MUST trigger privacy risk and DPIA screening in REG04 for high-risk processor relationships and material third-party privacy changes before approval, with the REG04 reference recorded in REG08.
For SMEs, the Third-Party and Supplier Security Policy establishes the pre-engagement review requirement:
Prior to engagement, each supplier must be reviewed for potential risks. This review must include:
The operational message is clear. Supplier risk is assessed before approval, not after signature.
This also supports NIS2 and DORA. NIS2 Article 21 requires supply chain security as part of cybersecurity risk-management measures. DORA Articles 28 to 30 require financial entities to manage ICT third-party risk, perform pre-contract assessments, maintain contractual safeguards, understand subcontracting risk, monitor dependencies, and plan exits for critical or important functions.
If a vendor touches PII or supports privacy-critical processing, the privacy risk record should show the vendor, processing role, data location, subprocessor dependency, contract safeguards, incident commitments, retention rules, monitoring approach, and exit plan.
One workflow, many compliance outcomes
The advantage of an integrated PIMS workflow is that the same evidence supports multiple frameworks without duplicating work.
| Obligation area | What the privacy risk workflow should show | Clarysec anchor |
|---|---|---|
| GDPR accountability | Processing purpose, lawful basis, data categories, risk to individuals, DPIA decision, controls, residual risk approval | REG02, REG04, Data Protection and Privacy Policy |
| ISO/IEC 27701:2025 PIMS | Role-aware privacy governance for controller, processor, joint controller, and subprocessor contexts | Privacy Risk Assessment and DPIA Policy |
| ISO/IEC 27001:2022 ISMS | Risk criteria, risk assessment, treatment plan, Statement of Applicability, retained evidence | Risk Management Policy, Risk Register and SoA Builder |
| NIS2 | Cybersecurity risk management, supply chain security, incident handling, management accountability | Zenith Controls mappings to 5.34, 5.9, 5.19 and related Annex A controls |
| DORA | ICT risk management, third-party register, critical dependency mapping, incident process, exit planning | Processor, Subprocessor and Third-Party Privacy Management Policy |
| NIST CSF 2.0 | Current and target profiles, governance outcomes, risk register or POA&M, supplier risk outcomes | Zenith Blueprint risk management steps |
| COBIT 19 and ISACA assurance | Governance ownership, control design, performance monitoring, management reporting, issue remediation | Quarterly review and internal privacy audit evidence |
NIST CSF 2.0 is especially useful for executive communication. Its GOVERN function covers organizational context, risk management strategy, policy, roles, oversight, and supply chain risk. Its Organizational Profiles help translate current and target outcomes into a prioritized action plan, such as a risk register or plan of action and milestones.
For organizations subject to NIS2, DORA, or sector-specific rules, privacy risk evidence also supports cybersecurity governance, supplier oversight, incident readiness, and resilience reporting.
Privacy risk treatment is broader than encryption
Encryption is important, but it cannot fix an invalid lawful basis, excessive collection, undisclosed profiling, unfair processing, unlawful retention, or a processor acting outside instructions.
The SME Data Protection and Privacy Policy states:
Controls must be implemented to reduce identified risks, including encryption, anonymization, secure disposal, and access restrictions
Those are strong examples, but treatment must fit the scenario. A privacy risk treatment plan may include narrowing the processing purpose, removing unnecessary data categories, aggregating or pseudonymising data, updating notices, changing lawful basis where appropriate, limiting retention, restricting access, adding logging, updating contracts, completing a DPIA, delaying launch, or rejecting processing that remains unacceptable.
The Enterprise Risk Management Policy reinforces treatment planning for risks above tolerance:
All risks classified above the tolerance level shall have an associated Risk Treatment Plan specifying:
In practice, this means high privacy risk cannot be accepted by silence. It must be treated, transferred where appropriate, avoided, or formally accepted by the right accountable owner.
Review triggers keep the assessment alive
A privacy risk assessment that is never revisited becomes stale evidence. ISO/IEC 27001:2022 clauses 8.2 and 8.3 require risk assessment and treatment at planned intervals or when significant changes occur. GDPR accountability expects current decisions. ISO/IEC 27701:2025 depends on monitoring and continual improvement.
A REG04 assessment should be reopened when the purpose changes, new data categories are added, special-category data becomes involved, lawful basis changes, a processor or subprocessor changes, storage moves to a new region, retention periods change, profiling logic changes, a breach or near miss occurs, customer contracts change, or a new NIS2, DORA, or sector-specific obligation applies.
Incident processes should feed back into the privacy risk workflow. NIS2 Article 23 establishes staged significant incident reporting. DORA Articles 17 to 20 require ICT-related incident recording, classification, escalation, communication, root-cause analysis, and improvement. GDPR personal data breach obligations may also be triggered. If an incident reveals weak access controls, excessive retention, unclear vendor notification, or poor customer instructions, REG04 must be updated.
What auditors will expect to see
A strong privacy risk workflow should withstand multiple assurance lenses.
| Auditor lens | Likely evidence request | What good looks like |
|---|---|---|
| ISO/IEC 27001:2022 auditor | ISMS scope, risk method, risk register, SoA, treatment plans, operational evidence | Privacy risks use approved criteria, link to Annex A controls, have owners, and are reviewed after changes |
| ISO/IEC 27701:2025 PIMS auditor | PII inventory, role context, privacy screening, DPIA records, controller and processor evidence | REG02 and REG04 show how processing is screened, rated, treated, approved, and reviewed |
| GDPR-focused reviewer | Lawful basis, transparency, DPIA rationale, processor contracts, breach decisions, data subject rights impact | The organization can demonstrate lawful, fair, necessary, proportionate, and controlled processing |
| NIST CSF assessor | Current and target profiles, governance outcomes, risk register, supplier risk outcomes | Privacy and cyber risks are communicated through enterprise risk language and prioritized plans |
| DORA assurance team | ICT risk framework, third-party register, critical function mapping, incident process, exit strategies | Privacy-relevant ICT dependencies are visible, contracted, monitored, tested, and tied to resilience |
| COBIT 19 or ISACA auditor | Governance ownership, control design, reporting, issue remediation | Privacy risk decisions are owned by business and management bodies, not hidden in legal or IT silos |
The Enterprise Data Protection and Privacy Policy also requires internal audit activity:
An internal privacy compliance audit shall be conducted annually or upon major organizational or regulatory changes. Audit scope shall include:
That creates a management feedback loop. Are REG02 records complete? Are REG04 screenings timely? Are DPIAs performed when required? Are high residual risks approved? Are vendor changes captured? Are treatment plans closed? Are notices aligned with actual processing?
Checklist for your next privacy change meeting
Use this checklist before a new processing activity, product feature, vendor, model, or support workflow goes live.
| Question | If the answer is yes, record this |
|---|---|
| Is this new or materially changed PII processing? | Open or update REG02 and trigger REG04 screening |
| Does the purpose, lawful basis, data category, retention, or recipient change? | Update processing inventory and lawful basis evidence |
| Could the processing create elevated risk to individuals? | Rate inherent privacy risk and document rationale |
| Is profiling, large-scale monitoring, special-category data, or vulnerable individuals involved? | Evaluate whether a DPIA is required |
| Is a new processor, subprocessor, cloud service, or support vendor involved? | Trigger supplier privacy and security review |
| Are controls required before launch? | Create treatment plan with owner and due date |
| Does residual risk remain above tolerance? | Escalate for approval before processing begins or continues |
| Will privacy notices, contracts, or customer instructions change? | Assign legal and customer-facing updates |
| What will trigger reassessment? | Set review date and change triggers in REG04 |
This checklist is not a replacement for policy. It is a practical way to operationalize policy in product, procurement, engineering, compliance, legal, and leadership meetings.
Turn privacy accountability into a working system
ISO/IEC 27701:2025 and GDPR accountability require more than documents. They require a working system that connects processing records, lawful basis, privacy risk, DPIA decisions, suppliers, controls, owners, approvals, and evidence.
Start with the Zenith Blueprint Risk Management phase, especially Steps 9 to 13. Use the Risk Register and SoA Builder to connect assets, threats, vulnerabilities, privacy risks, treatment decisions, and control references. Then use Zenith Controls to map PII protection, asset inventory, and supplier security into GDPR, ISO/IEC 27001:2022, NIS2, DORA, NIST CSF 2.0, and COBIT 19 assurance expectations.
Align the operating policies that make the workflow enforceable: Privacy Risk Assessment and DPIA Policy, PII Processing Inventory and Lawful Basis Policy, Processor, Subprocessor and Third-Party Privacy Management Policy, Risk Management Policy, and Data Protection and Privacy Policy. Smaller teams can also use Clarysec’s SME policies, while larger organizations can structure governance through Enterprise policies.
If your team is launching new processing, changing vendors, preparing for ISO/IEC 27701:2025, or trying to make GDPR accountability evidence repeatable, start with one live processing activity. Open REG02, run REG04 screening, map the risks to controls, assign treatment owners, and review residual risk with the right decision-maker.
That single workflow is where privacy governance becomes operational.
About the Author
Igor Petreski
Compliance Systems Architect, Clarysec LLC
Igor Petreski is a cybersecurity leader with over 30 years of experience in information technology and a dedicated decade specializing in global Governance, Risk, and Compliance (GRC).Core Credentials & Qualifications:• MSc in Cyber Security from Royal Holloway, University of London• PECB-Certified ISO/IEC 27001 Lead Auditor & Trainer• Certified Information Systems Auditor (CISA) from ISACA• Certified Information Security Manager (CISM) from ISACA • Certified Ethical Hacker from EC-Council