Framework·GDPR · Article 25·PDF · Free download

The RuleMesh Privacy by Design Framework

A GDPR-grounded operating model for building, governing, and evidencing data protection by design and by default — organised into seven implementation pillars, from Article 25 first principles to audit-ready evidence.

layers7 implementation pillarsaccount_treeObligation → control → evidencetrending_upMaturity model + roadmap
downloadDownload the toolkitRead the framework arrow_downward
§ 01Orientation

How to use this framework

Privacy by design is the practice of building data protection into a system’s architecture from the outset; under GDPR it is the binding obligation in Article 25 — “data protection by design and by default.” It is widely endorsed and rarely operationalised, and the reason is structural: an obligation is not something an engineering team can build directly. Between the legal text and a running system sits a translation problem that most organisations solve by hand, per project, inconsistently — and cannot later prove they solved.

This framework removes that gap. It decomposes the privacy-by-design obligation into the same four layers RuleMesh maintains in its GDPR rule graph — regulation → IT requirement → control → evidence — and organises GDPR’s privacy-by-design surface into seven implementation pillars that a CIO, CTO, or compliance head can assign, sequence, and audit.

domainUse 1

Standalone operating model

Any organisation can adopt the seven pillars, checklists, evidence list, and maturity model — with or without RuleMesh tooling.

account_treeUse 2

Map of the RuleMesh rule graph

For teams using RuleMesh, it shows how the structured model resolves an obligation all the way down to controls and evidence.

workUse 3

Executive briefing

Gives leadership a defensible way to direct engineering teams, sequence work by risk, and demonstrate accountability.

The full toolkit includes per-pillar requirement tables, the maturity self-assessment, and the evidence checklist — as a downloadable PDF.

downloadDownload the full toolkit
§ 02The model

The RuleMesh model: from regulation to evidence

Privacy by design is, operationally, the discipline of connecting the policy layer (what the regulation requires) to the execution layer (code, configuration, data, infrastructure) — reliably, and provably. RuleMesh maintains that connection as a structured graph with four layers.

REGULATION(policy layer)
GDPR Article 25(2): “…by default only personal data which are necessary for each specific purpose…”
IT REQUIREMENT(structured rule)
“Implement data protection by default controls: minimal collection, least-privilege access, automated retention.”
+ compliance DSL + checklist + risk + responsible role
CONTROL(execution layer)
Cloud / NIST CSF / OWASP controls that satisfy the requirement, grouped with a coverage-strength score.
EVIDENCE(proof)
The artefacts that prove the control is in place: config snapshots, access matrices, deletion logs, DPIAs.

Each layer is explicit and machine-readable. An IT requirement is not prose advice — it carries a compliance DSL statement, a compliance checklist, a risk level, an impact area, a responsible role, a technical-necessity score, and a list of required evidence. This is what makes the model deterministic: the same obligation resolves to the same structured requirement every time.

Example compliance DSL — Art. 25(2) data-protection-by-default (collection minimisation)

SHALL configure data collection interfaces IN web forms, APIs,
and user interfaces
TO collect ONLY personal data fields strictly necessary FOR each
specific processing purpose
BY removing or disabling unnecessary fields BY DEFAULT ;
EVIDENCE: form schemas, API specifications, field-level data mapping,
data minimisation review records, configuration change logs
§ 03Article 25

Article 25 in depth: the core of privacy by design

Article 25 decomposes into four IT requirements in the RuleMesh graph. These are the literal heart of a privacy-by-design programme. All four are HIGH risk with technical-necessity scores above 0.85.

Art. 25(1)High risknecessity 0.85Privacy Engineer / DPO

Privacy by design measures

Implement privacy-by-design technical and organisational measures — including pseudonymisation and data minimisation — into processing systems at the design stage and during active processing, proportionate to the risks.

  • checkPrivacy-by-design review conducted at the architecture stage before development begins?
  • checkRisk register maintained mapping processing risks to specific technical controls?
  • checkPseudonymisation mechanisms implemented, identifying information stored separately?
  • checkData minimisation controls enforced at collection, processing, and storage layers?
Art. 25(2)High risknecessity 0.88Software Engineer / Privacy Engineer

Data protection by default: minimal collection

Collect only the minimum fields strictly necessary for each purpose, with unnecessary fields disabled by default.

  • checkAll collection forms and APIs reviewed so only necessary fields are collected per purpose?
  • checkUnnecessary fields disabled or removed by default?
  • checkDocumented mapping of data fields to specific processing purposes?
Art. 25(2)High risknecessity 0.92IAM Engineer / Security Engineer

Data protection by default: least-privilege access

Role-based access controls ensuring personal data is not accessible by default to an indefinite number of persons, restricted to roles that require it for the specific purpose.

  • checkRBAC implemented across all systems processing personal data?
  • checkAccess restricted to authorised roles only — no default-open access?
  • checkAccess review reports generated periodically?
Art. 25(2)High risknecessity 0.87Data Engineer / Privacy Engineer

Data protection by default: storage limitation

Automated retention and storage-limitation controls so personal data is stored only for the period necessary per purpose, with automatic deletion or anonymisation on expiry.

  • checkRetention periods defined for all personal data categories per processing purpose?
  • checkAutomated deletion or anonymisation triggered on retention expiry?
  • checkDeletion operations logged and auditable?
Cross-article reachWhy Article 25 reaches across the whole regulation. Art. 25(1) names data-protection principles (Article 5), pseudonymisation and security (Article 32), and risk (Article 35). Article 32(1) carries a 0.95 technical-necessity encryption requirement; Article 5(2) carries the accountability/audit-logging requirement that makes everything else demonstrable. That cross-article reach is exactly why the seven pillars below define the operating model.
§ 04Pillars

The seven pillars

GDPR’s privacy-by-design surface organises into seven implementation pillars — the thematic requirement bundles in the RuleMesh graph. They structure the regulation’s obligations into requirements that each carry a risk level, a responsible role, a compliance checklist, and a control-framework mapping. All seven are HIGH priority and cross-article.

#PillarArticlesReq.Checklist
1Lawful Basis & Consent Engineering7 articles1154
2Breach & Change Notification Pipeline8 articles1679
3Data Subject Rights Operations9 articles1580
4Access Control & Security Measures11 articles1995
5Controller Governance & Accountability15 articles32150
6Codes, Certifications & BCR Compliance4 articles941
7International Transfer Governance9 articles1677
1

Lawful Basis & Consent Engineering

Articles 6, 7, 8, 9, 12, 13, 22

Auditable lawful-basis and consent capture for every processing purpose.

Consent Management Platform recording auditable proof of consent — timestamp, version, exact text — with one-click withdrawal.

11 requirements54 checklist items51 evidence items
Risk profile: 9 High, 2 Moderate
downloadGet full requirement index
2

Breach & Change Notification Pipeline

Articles 6, 13, 14, 17, 18, 19, 33, 34

Automated breach detection, escalation, multi-party notification.

End-to-end breach pipeline: processor-to-controller alerting + controller-to-supervisory-authority notification within 72 hours.

16 requirements79 checklist items74 evidence items
Risk profile: 14 High, 2 Moderate
downloadGet full requirement index
3

Data Subject Rights Operations

Articles 11, 12, 15, 16, 20, 21, 22, 26, 28

Intake, fulfilment, and audit trails for all data-subject rights.

SAR system covering all Art. 15(1)(a)–(h) fields; portability in structured machine-readable formats; automated marketing opt-out suppression.

15 requirements80 checklist items76 evidence items
Risk profile: 10 High, 5 Moderate
downloadGet full requirement index
4

Access Control & Security Measures

Articles 5, 9, 10, 18, 22, 23, 28, 29, 32, 34, 47

Encryption, access controls, and security safeguards across systems.

Pseudonymisation and encryption at rest (AES-256) and in transit (TLS 1.2+), KMS with key rotation. Technical necessity score: 0.95.

19 requirements95 checklist items89 evidence items
Risk profile: 17 High, 2 Moderate
downloadGet full requirement index
5

Controller Governance & Accountability

Articles 10, 11, 24, 25, 26, 27, 28, 30, 31, 32, 35, 36, 37, 38, 39

RoPA, DPO mandate, DPIA, organisational accountability.

Both Article 25 requirements live here — alongside RoPA, DPIA gate, and DPO mandate. The largest pillar and the foundation every other rests on.

32 requirements150 checklist items144 evidence items
Risk profile: 18 High, 14 Moderate
downloadGet full requirement index
6

Codes, Certifications & BCR Compliance

Articles 24, 40, 41, 47

Evidencing adherence to codes, certifications, and BCR commitments.

Article 25(3) makes certification "an element to demonstrate compliance." This pillar operationalises that track.

9 requirements41 checklist items35 evidence items
Risk profile: 1 High, 7 Moderate, 1 Low
downloadGet full requirement index
7

International Transfer Governance

Articles 14, 15, 20, 44, 45, 46, 47, 48, 49

Register, safeguard, and monitor all cross-border transfers.

Transfer-compliance system enforcing Chapter V conditions before any third-country transfer, including onward transfers.

16 requirements77 checklist items71 evidence items
Risk profile: 10 High, 6 Moderate
downloadGet full requirement index

Get the full requirement tables. Every requirement across the seven pillars, with roles, risk levels, and evidence lists.

downloadDownload the toolkit PDF
§ 05Evidence

The evidence model

Article 5(2) — accountability — means privacy by design is incomplete until it is demonstrable. Each IT requirement names the evidence that proves it, drawn from a vocabulary of 22 reusable evidence archetypes.

audit_logs·policy_doc·procedure_doc·approval_record·security_metrics·audit_report·dr_drill_report·config_snapshot·architecture_doc·siem_alerts·detections_report·config_rule·backup_restore_report·training_record·scan_report·change_ticket·pentest_report·code_repo·vuln_scan·compliance_assessment·incident_report·sbom_evidence

Evidence serves three audiences at once — and a privacy-by-design programme should be explicit about all three:

shield_person

Internal governance

The DPO and leadership tracking whether measures are actually in place.

gavel

External auditors

Supervisory authorities who expect design-decision records, DPIAs, access matrices, and deletion logs on request.

handshake

Enterprise customers

Who increasingly require this in vendor security and privacy assessments.

Evidence signals reportAn evidence signals report ties each obligation to the controls implemented and the artefacts that prove it. This is the difference between documentation compliance (a policy says you do it) and operational compliance (the system shows you do it) — the distinction at the centre of a credible privacy-by-design programme.
§ 06Maturity

The Privacy by Design Maturity Model

Use this to locate where your organisation is today and to define the next increment. The levels are cumulative.

L0

Ad hoc

Privacy addressed reactively. Obligations live in policy prose, not systems.

EvidenceNarrative; assembled under pressure.
L1

Accountable

Most common starting point

Pillar 5 established: RoPA maintained, lawful bases recorded, DPO/ownership clear, a DPIA gate exists.

EvidenceRoPA, DPIA register, lawful-basis register.
L2

Engineered by default

Article 25(2) defaults enforced in systems: minimal collection, least-privilege access, purpose-bound retention, encryption.

EvidenceConfig snapshots, access matrices, retention schedules, KMS/encryption records.
L3

Operational

Data-subject rights, breach notification, and transfers run as automated workflows with SLAs.

EvidenceRequest logs, breach register, 72h notification trails, transfer register.
L4

Evidenced & continuous

Every obligation mapped to controls and producing evidence; coverage monitored continuously.

EvidenceContinuous, queryable, traceable obligation→control→evidence chain.
Most organisations that “do privacy by design” sit at L1–L2 for governance and security but L0 for evidence — they have the measures and cannot prove them. The model’s purpose is to make that gap visible and close it deliberately.

downloadDownload the maturity self-assessment →

§ 07Sequencing

Where to start: a risk-sequenced roadmap

All seven pillars are HIGH priority, so sequencing is by dependency and risk, not importance.

Phase 0

Foundation (Pillar 5 core)

  • Stand up the RoPA (Art. 30(1))
  • Establish the lawful-basis register (Art. 6(1))
  • Create the DPIA gate (Art. 35(1))
  • Establish DPO/ownership (Art. 37–39)
flagOutcome: Reach maturity L1
Phase 1

By default (Pillars 5 + 4 + 1)

  • Implement collection minimisation (Art. 25(2), necessity 0.88)
  • Implement least-privilege access (Art. 25(2), necessity 0.92)
  • Implement automated retention (Art. 25(2), necessity 0.87)
  • Implement encryption and pseudonymisation (Art. 32(1)(a), necessity 0.95)
  • Wire consent capture (Art. 7)
flagOutcome: Reach L2 — privacy-by-design core is live
Phase 2

Operate (Pillars 3 + 2)

  • Data-subject-rights intake and fulfilment (Art. 15, 16, 17, 20, 21)
  • Breach pipeline (Art. 33, 34) — the 72-hour clock is live
flagOutcome: Reach L3
Phase 3

Govern the edges (Pillars 7 + 6)

  • Transfer governance (Art. 44–49)
  • Codes, certifications, and BCRs (Art. 40–42, 47)
flagOutcome: Complete the surface
Continuous

Evidence (cross-cutting)

  • Capture the evidence each requirement names from Phase 0 onward
  • Do not defer — retrofitting evidence is the most common reason programmes stall at L2
flagOutcome: Reach L4
downloadFree toolkit download

Get the full Privacy by Design Toolkit

The downloadable toolkit packages everything above into a reference PDF — including the complete per-pillar requirement tables, the maturity self-assessment, and the evidence checklist.

  • check_circleFull per-pillar requirement index (every requirement with roles and risk levels)
  • check_circlePer-requirement evidence lists drawn from 22 reusable archetypes
  • check_circleMaturity self-assessment template
  • check_circleCompliance DSL grammar reference
  • check_circleEvidence archetype glossary

Download the framework toolkit

Free. Double opt-in — we’ll send a confirmation link first.

Double opt-in. No spam. Unsubscribe any time. RuleMesh is the data controller — see our Privacy Policy.

§ 08Adoption

Using this framework with and without RuleMesh tooling

description

Without any RuleMesh tooling

This framework is a complete operating model on its own. Adopt the seven pillars as workstreams, assign each requirement’s responsible role, work the compliance checklists as acceptance criteria, and collect the named evidence per requirement. A compliance head can run a credible GDPR privacy-by-design programme from this document alone.

account_tree

With the RuleMesh rule graph (and MCP)

The structured model is queryable: each obligation resolves to its requirements, DSL, controls, and evidence without re-interpreting the regulation per team. The RuleMesh MCP provides verification assistance — it surfaces where evidence appears to exist — and reports only file names where evidence is detected; it does not access file contents or certify compliance.

Explore the MCParrow_forward
task_alt

With the RuleMesh Jira integration

The Jira integration turns each requirement into trackable work (To Do → AI Implementation Started → Evidence Detected → Human Verified → Completed) and produces the evidence signals report automatically. This is an accelerator, not a prerequisite — the framework stands without it.

Explore the Jira apparrow_forward
A principle holds across all three: AI agents and engineers can implement; humans govern. RuleMesh is the structured layer that makes the implementation consistent and the governance provable. It is Engineered Compliance Infrastructure, not a compliance service.
§ 09FAQ

Privacy by design: frequently asked questions

What is privacy by design?

Privacy by design is the practice of building data protection into a system’s architecture from the outset rather than adding it afterwards. Under the EU GDPR it is a binding legal obligation — Article 25, "data protection by design and by default" — requiring organisations to embed measures such as pseudonymisation and data minimisation at design time and to make the most privacy-protective settings the default.

Is privacy by design a legal requirement?

Yes, in the EU. Under GDPR Article 25 it is a binding obligation on data controllers, enforceable with fines up to €10 million or 2% of global annual turnover (Article 83(4)).

What is the difference between privacy by design and privacy by default?

Privacy by design (Article 25(1)) means data protection is built into the system from the design stage. Privacy by default (Article 25(2)) means the most privacy-protective settings apply automatically — minimal collection, least-privilege access, and purpose-bound retention — without the user having to act.

What does GDPR Article 25 require?

Article 25 requires controllers to implement appropriate technical and organisational measures (such as pseudonymisation and data minimisation) both at the time the means of processing are determined and during processing, and to ensure that by default only the personal data necessary for each specific purpose is processed.

Does Article 25 apply to processors?

The Article 25 design-and-default obligation binds the controller. Processors carry related obligations under Articles 28 and 32 and must support controllers in meeting theirs.

How do you implement privacy by design?

Put a privacy review and DPIA gate at design time; implement data minimisation, pseudonymisation/encryption, least-privilege access, and automated retention at the data layer; make defaults privacy-protective; map each obligation to the controls that satisfy it; and generate audit-ready evidence for every measure.

Who is responsible for privacy by design in an organisation?

The legal obligation sits with the controller. Operationally the CIO or CTO is accountable for the technical and organisational measures; the Data Protection Officer advises and monitors but cannot be made to carry the controller’s accountability.

Sources & further reading: GDPR Article 25 · EDPB Guidelines 4/2019 · ICO guidance · Ann Cavoukian, “Privacy by Design: The 7 Foundational Principles” (2009) · GDPR Article 83(4) (penalties).

Ready to implement privacy by design?

Download the full toolkit, explore the RuleMesh rule graph, or start with a free local scan.

downloadDownload the toolkitRun a free local scan arrow_forward