What is the Privacy Technologist’s Role in the Context of an Organisation?

1. The Maturation of Privacy Engineering and the Purple Belt Mandate

The discipline of privacy has undergone a fundamental transition from a purely jurisprudential and regulatory abstraction into a rigorous, deterministic engineering domain. Historically, privacy was relegated to compliance departments, managed via static policies, contractual terms, and retroactive auditing. However, the proliferation of hyper-scale cloud computing, sensor-based surveillance, and the pervasive integration of artificial intelligence (AI) has rendered contractual safeguards and policy-based compliance insufficient. In the modern enterprise, privacy must be architected into the fundamental topology of information systems.

This operational paradigm shift necessitates the presence of the privacy technologist—a specialised practitioner operating at the intersection of systems engineering, legal compliance, and human-centric design. The privacy technologist bridges the critical gap between regulatory mandates and functional code, translating jurisprudence into deterministic engineering constraints. This operational maturity scale progresses from foundational awareness of regulations through intermediate implementation, culminating in the expert-level orchestration required of the Purple Belt practitioner. At this advanced stage, the privacy technologist does not merely interpret the law but engineers the organisation’s technological infrastructure to enforce it autonomously.

A persistent fallacy within the technology sector is the conflation of security with privacy. While the two disciplines are inextricably linked, they solve fundamentally different problems. Information security is concerned with the Confidentiality, Integrity, and Availability (CIA) triad, protecting data against unauthorised access and malicious actors. Privacy engineering, conversely, is concerned with the authorised, yet potentially harmful, processing of data. A system can be perfectly secure—employing advanced encryption and rigid access controls—while simultaneously functioning as a highly invasive privacy threat if it aggregates personal data for undisclosed secondary uses or employs algorithms that infer sensitive attributes. Dispelling the misinformation that “security equals privacy” or that “shifting trust to a VPN increases privacy” is a primary responsibility of the privacy technologist. The technologist must architect systems that address privacy-specific objectives, primarily predictability, manageability, and disassociability, ensuring that authorised processing does not generate moral or tangible harms.

2. The Dutch Regulatory Paradigm and the Autoriteit Persoonsgegevens

For organisations operating within the Netherlands, the Autoriteit Persoonsgegevens (AP) dictates strict operational boundaries, particularly concerning the procurement, integration, and management of Cloud Service Providers (CSPs). The AP has established a rigorous framework clarifying that government entities and private enterprises acting as the Verwerkingsverantwoordelijke (Controller) retain full, non-delegable accountability for personal data processing, even when utilising centralised framework agreements, known as mantelovereenkomsten.

The privacy technologist must ensure that the Verwerkingsverantwoordelijke conducts an independent, context-specific risk analysis prior to deploying any CSP. This requires the execution of a comprehensive Data Protection Impact Assessment (DPIA) that evaluates specific deployment risks, such as state-actor threats, the processing of special category data, and the implications of cross-border data flows. The AP specifically notes that reliance on a central Strategic Supplier Management (SLM) function’s general DPIA is insufficient if the local deployment context alters the risk profile.

Furthermore, SLM functions must be professionalised and adequately resourced. The SLM acts as the centralised interface negotiating with hyperscale CSPs. When an SLM handles user management, license administration, or infrastructure provisioning on behalf of underlying government agencies, it assumes the legal role of a processor (Verwerker). The privacy technologist must ensure that explicit task descriptions and contractual guardrails are established between the Verwerkingsverantwoordelijke and the Verwerker to maintain compliance.

International data transfers initiated via CSPs require rigorous technical evaluation. The AP specifies that personal data routed outside the European Economic Area (EEA) must be protected by safeguards equivalent to European standards. The privacy technologist must architect supplementary technical measures to ensure compliance. If equivalent protection cannot be cryptographically or contractually guaranteed, the transfer must be halted.

The AP’s strategic priorities for 2026-2028 focus heavily on mitigating mass surveillance, regulating AI, and ensuring digital resilience. The AP aims to prevent a “surveillance society” where vulnerable demographics face indirect discrimination due to structural online monitoring. The privacy technologist must preemptively design systems that avoid disproportionate tracking, implementing architectural decentralisation to reduce the accumulation of sensitive data honeypots that attract both state and non-state threat actors.

3. Organisational Architecture and the Differentiation of Duties

The efficacy of privacy engineering is directly proportional to its structural placement within the enterprise. Traditional organisational charts often misalign privacy functions, treating them as late-stage compliance hurdles rather than core engineering parameters. To achieve predictable, scalable privacy, the organisation must adopt deliberate structural models that distribute accountability and embed technical expertise at the point of origin.

3.1 Horizontal versus Vertical Organisational Patterns

Organisational alignment for privacy engineers typically follows either a horizontal or vertical pattern. Vertical management features a siloed, top-down hierarchy where privacy requirements are dictated by an isolated legal or compliance department and handed down to engineering teams. While providing rigorous, centralised control, this model is highly prone to bureaucracy, slow decision-making, and a compliance-only mindset that treats privacy as a checkbox rather than a qualitative engineering attribute. This often leads to organisations focusing on paperwork rather than lasting systemic changes, resulting in repeated failures.

Horizontal, or matrix, management integrates privacy engineers directly into product development teams. This decentralised approach fosters rapid communication, autonomy, and cross-functional collaboration. By embedding privacy champions within development pipelines, the organisation ensures that privacy requirements are integrated into sprint backlogs and sprint reviews before code is committed to production.

The optimal approach hybridises these patterns. A centralised Privacy Council sets the enterprise-wide policy, standardises the interpretation of laws, and defines risk tolerance, while horizontal privacy engineers execute the technical implementation within individual business units. This ensures that value tensions between data utility and privacy are resolved collaboratively while maintaining agile deployment speeds.

3.2 The Three Lines of Defence Model

The Dutch organisational context relies heavily on the “Three Lines of Defence” model to allocate risk management responsibilities and maintain appropriate segregation of duties.

The first line of defence comprises the operational and engineering teams—the system owners, IT developers, and data stewards who directly handle and process personal data. They own the risk and are responsible for implementing technical controls natively within the architecture. The privacy technologist operates predominantly within this first line, translating policy into code, configuring access controls, and deploying obfuscation routines.

The second line of defence consists of the risk and compliance oversight functions, including the Privacy Officer and IT Risk managers. This line designs the policy frameworks, monitors the compliance of the first line, and provides specialised advice on mitigating emerging risks.

The third line of defence is internal audit, which provides independent, objective assurance regarding the effectiveness of the governance, risk management, and internal controls implemented by the first two lines.

3.3 The DPO versus The Privacy Technologist

A critical structural and operational distinction must be maintained between the Data Protection Officer (DPO), known in the Netherlands as the Functionaris voor Gegevensbescherming (FG), and the Privacy Technologist. The conflation of these roles leads to severe conflicts of interest and degrades the organisation’s compliance posture.

The FG is a formal, legally mandated role under GDPR Articles 37-39, required for government agencies and organisations conducting large-scale systematic monitoring or processing of special categories of data. The FG must operate with strict independence, advising the board, monitoring compliance, and acting as the official liaison to the AP. The FG operates strictly within the second or third line of defence. Crucially, the FG cannot determine the means and purposes of processing, nor can they implement technical controls, as doing so compromises their ability to independently audit those same controls.

Conversely, the Privacy Technologist is the tactical implementer operating within the first line of defence. While the FG states what the legal requirement is, the Privacy Technologist defines how it is mathematically and architecturally achieved. If the FG identifies a failure in data minimisation during a DPIA, they report the deficiency; the Privacy Technologist then designs and deploys data stripping algorithms, tokenisation microservices, or dynamic location granularity protocols to rectify the architecture. The two roles are symbiotic but must remain operationally distinct to preserve the integrity of the governance model.

4. Quantitative Privacy Risk Modelling: The FAIR Methodology

Historically, privacy risk assessments relied on qualitative rubrics—utilising arbitrary High, Medium, and Low scales—that yielded subjective, inconsistent, and ultimately unactionable results. To mature the discipline, the privacy technologist employs quantitative modelling, specifically utilising the Factor Analysis of Information Risk (FAIR) methodology adapted for privacy contexts.

FAIR deconstructs risk into constituent factors, enabling the probabilistic financial estimation of loss resulting from a privacy event. This shifts the paradigm from subjective guessing to empirical financial metrics, providing executives with actionable data regarding the Annualised Loss Expectancy (ALE).

The core formulation dictates that risk is the product of Loss Event Frequency (LEF) and Loss Magnitude (LM). In the extended FAIR taxonomy utilised for privacy quantification, the Annualised Loss Expectancy is calculated as follows:

ALE = LEF x (PLM + SLM)

In this equation, PLM represents the Primary Loss Magnitude, which includes direct costs such as incident response, forensic investigations, and system downtime. SLM represents the Secondary Loss Magnitude, which encompasses regulatory fines (such as those levied by the AP), litigation costs, and brand degradation.

The Loss Event Frequency (LEF) is determined by analysing the Threat Event Frequency (Attempt Frequency) against the system’s Vulnerability. Vulnerability, in the FAIR model, is defined as the probability that a threat attempt will successfully overcome the system’s defensive controls and result in a privacy harm. In a privacy context, the technologist evaluates specific factors driving the Attempt Frequency: Opportunity, Motivation, Capability, and Difficulty. Opportunity represents the affordances within the architecture that permit an actor to act; a centralised database provides greater opportunity for mass exfiltration than a decentralised, on-device processing model. Motivation represents the drive of the actor, while Capability represents their resources. Difficulty represents the architectural impediments implemented by the privacy technologist, such as strong cryptographic controls.

To calculate these metrics programmatically within IT infrastructure, relying on Governance, Risk, and Compliance (GRC) tooling, the formulas are parametrised based on empirical inputs:

In these formulations, the variables FAIR₁ through FAIR₈ represent specific, quantifiable inputs, such as the estimated frequency of threat actor contact, the probability of successful exploitation, the financial estimates for incident response, and the likelihood of severe regulatory consequences. By quantifying privacy risk in financial terms, the technologist bridges the communication gap with enterprise leadership, justifying the capital expenditure required for complex Privacy-Enhancing Technologies (PETs) by demonstrating the resultant reduction in the ALE.

To accurately scope the Loss Magnitude, the technologist must define the specific privacy harms occurring within the ecosystem. Daniel Solove’s Taxonomy of Privacy provides the comprehensive framework, classifying harms into four distinct domains. The first domain, Information Collection, encompasses Surveillance and Interrogation. The second domain, Information Processing, involves Aggregation, Identification, Insecurity, Secondary Use, and Exclusion. The third domain, Information Dissemination, includes Breach of Confidentiality, Disclosure, Exposure, Increased Accessibility, Appropriation, and Distortion. The final domain, Invasion, encompasses Intrusion and Decisional Interference. Decisional interference specifically involves the use of “dark patterns” to manipulate user consent, explicitly violating the fairness principles of the GDPR. The privacy technologist maps these specific harms to the FAIR model, ensuring that non-information privacy invasions—such as the physical intrusion of augmented reality users converging on a private residence—are quantified alongside traditional data breaches.

5. The NIST Privacy Framework

Core Functions and Objectives

To standardise the integration of privacy into the System Development Life Cycle (SDLC), the privacy technologist utilises the NIST Privacy Framework 1.1. Updated to align seamlessly with the NIST Cybersecurity Framework (CSF) 2.0, this framework provides a common lexicon for managing privacy risk decoupled from specific legal jurisdictions, focusing instead on practical, outcome-driven engineering activities.

The NIST Privacy Framework Core dictates five high-level functions that organise foundational privacy activities:

• Identify-P (ID-P): Developing the organisational understanding necessary to manage privacy risk. The technologist maps the data processing ecosystem, establishing exhaustive data inventories that track the origin, state, and lineage of personal data across microservices, ensuring all ecosystem parties and data flows are documented.
• Govern-P (GV-P): Establishing the governance structure to enable ongoing privacy risk management. This aligns with the implementation of the Privacy Council, the formalisation of enterprise risk tolerance, and the integration of privacy awareness training across the workforce.
• Control-P (CT-P): Developing activities to manage data with sufficient granularity to protect privacy. This involves the direct implementation of technical measures such as differential privacy, cryptographic hashing, and automated data lifecycle management to ensure data is disassociated and predictably managed.
• Communicate-P (CM-P): Enabling reliable understanding about data processing. The technologist designs transparent, multi-layered interfaces and user dashboards to facilitate informed consent, ensuring data subjects are aware of processing activities and can exercise their rights effectively.
• Protect-P (PR-P): Aligning with the CSF 2.0 to secure data against unauthorised access, maintaining the baseline security required to support overall privacy objectives.

The framework introduces specific engineering objectives that extend beyond the traditional CIA triad, focusing on the unique requirements of privacy engineering. The first objective, Predictability, requires enabling reliable assumptions by individuals and system owners regarding data processing. A predictable system eliminates surprise; if an application collects location data solely to route a vehicle, utilising that same data to infer religious affiliation based on visited locations violates predictability. The second objective, Manageability, necessitates providing the capability for granular administration of personal data, including alteration, deletion, and selective disclosure. The third objective, Disassociability, requires the processing of data or events without association to individuals or devices beyond the strict operational requirements. The technologist enforces disassociability through tactics such as k-anonymity, pseudonymisation, and temporal aggregation.

6. Hoepman’s Eight Privacy Design Strategies and 26 Tactics

To operationalise the outputs of the FAIR risk assessment and fulfill the architectural requirements of the NIST Privacy Framework, the privacy technologist applies Jaap-Henk Hoepman’s Eight Privacy Design Strategies. These strategies provide a structured methodology for translating abstract legal obligations into concrete architectural specifications, further subdivided into 26 specific technical tactics.

The first four strategies are data-oriented, focusing on the technical manipulation and structural containment of personal data within the system architecture.

The Minimise strategy requires limiting the processing of personal data to the absolute minimum necessary to achieve a specific objective. This strategy is executed through four distinct tactical approaches. The Exclude tactic mandates refraining from processing a data subject’s personal data entirely, often implemented at the ingestion layer by discarding specific payload fields before they reach persistent storage. The Select tactic involves deciding on a case-by-case basis the full or partial usage of personal data, akin to dynamic whitelisting. The Strip tactic involves removing unnecessary personal data fields from the system’s representation of each user, such as dropping the final octet of an IP address. The Destroy tactic requires completely removing a data subject’s personal data once the defined Bewaartermijnen (retention periods) have expired, employing cryptographic shredding to ensure unrecoverability.

The Hide strategy prevents the exposure of personal data and limits the interlinkability of distinct datasets. The Restrict tactic limits access to data purely on a need-to-know basis, utilising robust Role-Based Access Control (RBAC) or Attribute-Based Access Control (ABAC). The Mix tactic obscures the link between data subjects and their data by processing it alongside other subjects’ data, employing technologies like mix networks or onion routing. The Obfuscate tactic involves altering the data to prevent clear identification, using techniques such as format-preserving encryption, fuzzy hashing, or adding cryptographic noise. The Dissociate tactic breaks the logical link between an identity and the data, heavily relying on pseudonymisation techniques.

The Separate strategy involves processing data in a distributed fashion to prevent centralised aggregation and single points of privacy failure. The Isolate tactic requires storing data in separate, unconnected databases or physical environments. The Distribute tactic requires processing data across multiple independent nodes or edge devices, rather than centralising it within a single cloud repository, thereby limiting the blast radius of any potential compromise.

The Abstract strategy limits the detail of the personal data processed. The Group tactic clusters users into cohorts, replacing individual identifiers with group characteristics. The Summarize tactic provides macroscopic metrics rather than granular records. The Perturb tactic applies mathematical noise into query results, often leveraging Differential Privacy to deplete a “privacy budget,” mathematically guaranteeing that an individual’s presence in a dataset cannot be determined through repeated querying.

The subsequent four strategies are process-oriented, focusing on the organisational workflows, user interfaces, and governance mechanisms.

The Inform strategy provides transparency regarding processing activities. The Supply tactic involves providing layered privacy notices detailing data usage. The Explain tactic requires providing comprehensible reasoning for automated decisions, ensuring algorithmic transparency. The Notify tactic mandates alerting data subjects promptly in the event of a data breach or significant change in processing terms.

The Control strategy provides the data subject with agency over their data. The Consent tactic requires implementing unambiguous, opt-in mechanisms prior to processing. The Choose tactic provides granular privacy dashboards allowing users to select or exclude specific processing activities. The Update tactic ensures data subjects have the means to rectify inaccurate data. The Retract tactic provides mechanisms enabling the Right to Erasure, allowing users to withdraw consent and trigger automated data deletion workflows.

The Enforce strategy represents a commitment to processing personal data securely and lawfully. The Create tactic involves establishing robust policies and technical constraints. The Maintain tactic requires regularly reviewing and updating systems to address new threats. The Uphold tactic involves enforcing core privacy values through strict technical controls, ensuring that policy dictates are not bypassed by operational expediency.

The Demonstrate strategy provides evidence of compliance, adhering to the GDPR Accountability principle. The Record tactic involves secure, immutable logging of processing activities without logging the raw personal data itself. The Audit tactic mandates executing regular code and access reviews to examine day-to-day activities for risks. The Report tactic requires generating automated compliance dashboards to analyse tests and logs, providing verifiable evidence of compliance to internal regulators and external supervisory authorities like the AP.

7. Technical Translation: GDPR Article 25 and Cloud Infrastructure

The mandate of GDPR Article 25, Data Protection by Design and by Default (DPbDD), requires that appropriate technical and organisational measures are integrated into processing activities from their inception. The EDPB Guidelines 4/2019 dictate that controllers must continually assess the “state of the art,” meaning that the privacy technologist must stay abreast of technological advancements and deploy Privacy-Enhancing Technologies (PETs) commensurate with the identified risk. Implementation must be effective, producing intended, verifiable results.

To achieve this, the privacy technologist maps the legal requirements to practical Cloud services across the major hyperscalers. The architectural advice must adhere to Ann Cavoukian’s 7 Foundational Principles of Privacy by Design: Proactive not Reactive; Privacy as the Default Setting; Privacy Embedded into Design; Full Functionality (Positive-Sum); End-to-End Security (Full Lifecycle Protection); Visibility and Transparency; and Respect for User Privacy.

The following table demonstrates the technical translation of GDPR requirements and the 7 Principles of Privacy by Design into specific cloud architectural implementations, comparing PETs across Amazon Web Services (AWS), Google Cloud Platform (GCP), and Microsoft Azure.

GDPR Mandate & PbD Principle	Architectural Strategy (Hoepman)	AWS Implementation	GCP Implementation	Azure Implementation	Technical Implementation Rationale
Data Minimisation (Art 5.1.c) PbD: Privacy as Default	Minimise (Strip / Destroy)	S3 Lifecycle Policies & Amazon Macie	Cloud Storage Object Lifecycle & Sensitive Data Protection (DLP)	Blob Storage Lifecycle Management & Microsoft Purview	Automates the Destroy tactic by cryptographically purging objects post-Bewaartermijn. Data Loss Prevention (DLP) APIs automate the Strip tactic by identifying and redacting over-collected PII at the ingestion layer before persistent storage.
Integrity & Confidentiality (Art 5.1.f) PbD: End-to-End Security	Hide (Obfuscate / Restrict)	AWS Key Management Service (KMS) with Customer Managed Keys (CMEK)	Cloud Key Management Service (Cloud KMS) with External Key Manager (EKM)	Azure Key Vault with Dedicated HSM	Enforces the Restrict tactic by decoupling data access from key access. Utilising CMEK/EKM ensures the CSP has no logical access to the key material, fulfilling AP requirements for mitigating international data transfer risks.
Purpose Limitation (Art 5.1.b) PbD: Privacy Embedded into Design	Separate (Isolate)	Amazon VPC, Subnets, and Security Groups	Virtual Private Cloud (VPC) Service Controls	Azure Virtual Network (VNet) and Network Security Groups (NSG)	Enforces the Isolate tactic via strict logical segregation. Prevents lateral movement and unauthorised secondary use by isolating production environments processing personal data from analytics or development environments.
Accountability (Art 5.2) PbD: Visibility and Transparency	Demonstrate (Record / Audit)	AWS CloudTrail configured with S3 Object Lock	Cloud Audit Logs with Bucket Lock	Azure Monitor with Immutable Storage for Blob Data	Implements the Record and Audit tactics. Write-Once-Read-Many (WORM) configurations ensure immutable audit trails, preventing log tampering by malicious insiders and providing verifiable evidence of compliance during AP inspections.
Accuracy & Right to Erasure (Art 5.1.d, Art 17) PbD: Respect for User Privacy	Control (Update / Retract)	API Gateway triggering AWS Lambda functions for automated CRUD	API Gateway triggering Cloud Functions	Azure API Management triggering Azure Functions	Facilitates the Update and Retract tactics by exposing dedicated endpoints that allow data subjects to asynchronously execute asynchronous correction or erasure requests across all interconnected microservices.

By mapping policy to tangible architectural capabilities, the privacy technologist transforms compliance from an external audit function into an inherent, programmatic characteristic of the infrastructure.

8. The Interplay of AI, Large Language Models, and EDPB 2026 Directives

As organisational roadmaps extend into 2026, the intersection of privacy engineering and Artificial Intelligence requires immediate architectural prioritisation. The regulatory landscape has shifted significantly with the enforcement of the European AI Act, the Digital Omnibus on AI proposal, and the publication of specific EDPB guidelines regarding AI.

In 2026, the EDPB published Guidelines 1/2026 on the processing of personal data for scientific research and its interplay with the AI Act and the GDPR. These guidelines establish rigorous constraints on the processing of special categories of personal data (Article 9 GDPR) for AI training and bias detection. The processing of directly identifiable data is only permissible where it is strictly necessary and proportionate. The EDPB emphasises that organisations must not dilute the “strict necessity” standard when detecting bias in AI systems.

The privacy technologist must enforce robust safeguards when provisioning data for Machine Learning (ML) pipelines. This includes establishing Secure Processing Environments (SPEs) and applying advanced PETs. Rather than relying on simple data masking, the technologist must deploy k-anonymity—ensuring each individual’s data is indistinguishable from at least others in the dataset—and L-diversity—ensuring sufficient variation of sensitive attributes within the k-anonymous block—prior to releasing datasets to data science teams.

The deployment of Large Language Models (LLMs) introduces acute privacy vulnerabilities, notably data extraction attacks. As highlighted by the EDPB’s Support Pool of Experts, adversarial prompting can force an LLM to regurgitate memorised personal data present in its training corpus. The privacy technologist mitigates these risks via strict architectural constraints. Input sanitation is enforced by implementing intermediary firewalls that utilise Named Entity Recognition (NER) to detect and redact personal data from user prompts before they reach the LLM inference engine. Output filtering deploys secondary models to evaluate the generated text, blocking responses that contain potentially extracted personal data. Furthermore, the technologist must conduct rigorous document-based and empirical audits, employing Red Teaming methodologies to demonstrate the model’s resilience against membership inference and extraction attacks.

For enterprise AI deployments utilising Retrieval-Augmented Generation (RAG) architectures, the LLM retrieves context from internal vector databases. The privacy technologist must ensure that the vector database enforces the exact same Attribute-Based Access Controls (ABAC) as the primary data stores, ensuring the LLM cannot retrieve and expose data that the querying user is not authorised to access.

Within the Netherlands, the AP acts as the coordinating regulator for algorithms and AI, placing intense scrutiny on systems that pose risks to fundamental rights. A critical requirement enforced by the AP is “AI Literacy”—the statutory mandate that organisations ensure employees have sufficient knowledge and skills to use AI responsibly and understand algorithmic outputs. The privacy technologist supports this mandate by integrating explainability tools natively into the AI architecture, aligning with Hoepman’s Explain tactic. By implementing frameworks such as SHAP (SHapley Additive exPlanations) or LIME (Local Interpretable Model-agnostic Explanations), the technologist ensures that algorithmic decisions are interpretable. This allows human reviewers to exercise meaningful oversight, fulfilling the GDPR Article 22 requirement regarding automated decision-making and preventing automated bias.

9. Conclusion

The role of the privacy technologist is fundamentally one of translation, orchestration, and deterministic execution. As privacy laws globally converge toward stricter enforcement and greater technological specificity, the abstraction of legal text must be rigorously compiled into immutable system architecture. Operating within the exacting constraints of the GDPR, the EDPB 2026 directives, and the specific mandates of the Autoriteit Persoonsgegevens, the technologist protects the enterprise by systematically protecting the data subject.

Through the deployment of the NIST Privacy Framework 1.1, the mathematical quantification of risk via the FAIR methodology, and the tactical execution of Hoepman’s eight privacy design strategies, the privacy technologist constructs systems where data utility and fundamental human rights are not mutually exclusive. By embedding Privacy-Enhancing Technologies natively into hyperscale cloud infrastructure and automating compliance controls within the development pipeline, the technologist ensures that privacy by design is not a retroactive compliance artefact, but the default operational state of the modern digital organisation.

Sources and Further Reading

1. An Introduction to Privacy for Technology Professionals (Travis Breaux) (z-library.sk, 1lib.sk, z-lib.sk).pdf
2. Common Misconceptions – Privacy Guides https://www.privacyguides.org/en/basics/common-misconceptions/
3. Dutch DPA sets its course for 2026–2028 with three strategic priorities – Hogan Lovells  https://www.hoganlovells.com/en/publications/dutch-dpa-sets-its-course-for-20262028-with-three-strategic-priorities
4. Dutch Data Protection Authority – Wikipedia  https://en.wikipedia.org/wiki/Dutch_Data_Protection_Authority
5. ISACA Now Blog 2026 Five Practical Strategies to Address Privacy Engineering Challenges https://www.isaca.org/resources/news-and-trends/isaca-now-blog/2026/five-practical-strategies-to-address-privacy-engineering-challenges
6. Horizontal vs Vertical Management: Advantages and Differences – Rolebase  https://rolebase.io/en/blog/horizontal-vs-vertical
7. The Difference Between Horizontal & Vertical Organizations – TechnologyAdvice  https://technologyadvice.com/blog/information-technology/difference-vertical-horizontal-project-management/
8. FG – The Privacy CoOperation https://tpco.nl/en/fg/
9. The four pillars of a high performing privacy programme – PA Consulting  https://www.paconsulting.com/insights/the-four-pillars-of-a-high-performing-privacy-programme
10. The positioning of the Data Protection Officer (FG) within the Three Lines Model  https://privacy-web.nl/en/nieuws/de-positionering-van-de-functionaris-voor-gegevensbescherming-fg-binnen-het-three-lines-model/
11. Roles of Three Lines of Defense for Information Security and Governance – ISACA  https://www.isaca.org/resources/isaca-journal/issues/2018/volume-4/roles-of-three-lines-of-defense-for-information-security-and-governance
12. Privacy Officer versus Data Protection Officer: the differences – Projective Group  https://www.projectivegroup.com/privacy-officer-versus-data-protection-officer-the-differences/
13. DPO, Privacy Officer, Privacy Steward: What’s the difference? – Considerati  https://www.considerati.com/publications/dpo,-privacy-officer,-privacy-steward-what%E2%80%99s-the-difference.html
14. Differences in Roles and Responsibilities between a DPO & a Privacy Engineer | by Patrick Oh | DataFrens.sg | Medium https://medium.com/datafrens-sg/differences-in-roles-and-responsibilities-between-a-dpo-a-privacy-engineer-b869dae9c911
15. FAIR: A Framework for Revolutionizing Your Risk Analysis – CIS Center for Internet Security  https://www.cisecurity.org/insights/blog/fair-a-framework-for-revolutionizing-your-risk-analysis
16. Analyzing Privacy Risk Using FAIR – The FAIR Institute, accessed on May 15, 2026, https://www.fairinstitute.org/blog/analyzing-privacy-risk-using-fair
17. Quantitative Privacy Risk Analysis – National Institute of Standards and Technology https://www.nist.gov/document/quantitative-privacy-risk-analysis
18. Custom fields and formulas to represent the FAIR model – Drata Help Center  https://help.drata.com/en/articles/11593525-custom-fields-and-formulas-to-represent-the-fair-model
19. FAIR Beginner’s Guide: What Do the Numbers Mean? https://www.fairinstitute.org/blog/fair-beginners-guide-what-do-the-numbers-mean
20. Privacy Framework | NIST – National Institute of Standards and Technology  https://www.nist.gov/privacy-framework
21. Privacy Framework 1.1 | NIST – National Institute of Standards and Technology  https://www.nist.gov/privacy-framework/new-projects/privacy-framework-version-11
22. Privacy by Design strategies | Data Privacy Handbook – GitHub Pages  https://utrechtuniversity.github.io/dataprivacyhandbook/design-strategies.html
23. Privacy Design Strategies (The Little Blue Book) – Institute for Computing and Information Sciences  https://www.cs.ru.nl/~jhh/publications/pds-booklet.pdf
24. Privacy Design Strategies for the DECODE Architecture – European Commission  https://ec.europa.eu/research/participants/documents/downloadPublic?documentIds=080166e5b368f34c&appId=PPGMS
25. Unlocking Data Protection By Design & By Default: Lessons from the Enforcement of Article 25 GDPR – The Future of Privacy Forum  https://fpf.org/wp-content/uploads/2023/05/FPF-Article-25-GDPR-A4-FINAL-Digital.pdf
26. EDPB annual report 2025: supporting stakeholders through guidance and dialogue https://www.edpb.europa.eu/news/news/2026/edpb-annual-report-2025-supporting-stakeholders-through-guidance-and-dialogue_en
27. EDPB & EDPS issue Joint Opinion on the EU Digital Omnibus on AI – Reed Smith LLP  https://www.reedsmith.com/our-insights/blogs/viewpoints/102megs/edpb-edps-issue-joint-opinion-on-the-eu-digital-omnibus-on-ai/
28. EDPB-EDPS JOINT OPINION 1/2026 On the Proposal for a Regulation as regards the simplification of the implementation of harmonise https://www.edpb.europa.eu/system/files/2026-01/edpb_edps_jointopinion_202601_proposal_ai-omnibus_en.pdf
29. The European Data Protection Board Releases New Guidelines on the Processing of Personal Data for Scientific Research | Insights | Ropes & Gray LLP https://www.ropesgray.com/en/insights/alerts/2026/04/the-european-data-protection-board-releases-new-guidelines-on-the-processing-of-personal-data
30. Guidelines 1/2026 on processing of personal data for scientific research purposes – EDPB https://www.edpb.europa.eu/system/files/2026-04/edpb_guidelines_202601_scientificresearch_en.pdf
31. AI Privacy Risks & Mitigations Large Language Models (LLMs) – EDPB – European Union  https://www.edpb.europa.eu/our-work-tools/our-documents/support-pool-experts-projects/ai-privacy-risks-mitigations-large_en
32. EU: EDPB Opinion on AI Provides Important Guidance though Many Questions Remain https://privacymatters.dlapiper.com/2025/01/eu-edpb-opinion-on-ai-provides-important-guidance-though-many-questions-remain/
33. AI laws and regulations in the Netherlands| CMS Expert Guide – Cms.law https://cms.law/en/int/expert-guides/ai-regulation-scanner/the-netherlands
34. AI, Machine Learning & Big Data Laws and Regulations 2025 – Netherlands  https://www.globallegalinsights.com/practice-areas/ai-machine-learning-and-big-data-laws-and-regulations/netherlands/
35. AI literacy: AP calls organizations to action – PONT | Data & Privacy https://privacy-web.nl/en/nieuws/ai-geletterdheid-ap-roept-organisaties-op-tot-actie/
36. The Dutch AI & Algorithms Report: a call to action | Stibbe https://www.stibbe.com/publications-and-insights/the-dutch-ai-algorithms-report-a-call-to-action
37. Artificial intelligence | European Data Protection Board https://www.edpb.europa.eu/our-work-tools/our-documents/topic/artificial-intelligence_en