

- Description
- Vieux cadenas rouillé fermant le loquet d'une porte en bois
- Source
- Estormiz · original page
- Licence
- CC0 Public domain
Security, Privacy, Compliance
By design, a datamart concentrates data from many systems: it is a prime target and a risk multiplier. In a sales force application, it…
Level: 🟢→🔴 · Theme code: SEC
Why this theme#
By design, a datamart concentrates data from many systems: it is a prime target and a risk multiplier. In a sales force application, it contains data about people (sales reps, customer contacts, visit locations); GDPR therefore applies, with its principles (Article 5: lawfulness, purpose limitation, data minimization, accuracy, storage limitation, integrity and confidentiality), data protection by design (Article 25), records of processing activities (Article 30), security of processing (Article 32), impact assessment (Article 35), and data subject rights (access, erasure…). This is not legal advice: validate with your DPO. The risk of ignoring this topic is twofold: sanctions and loss of trust, but also operational blockage (inability to erase, prove, share). The technical implementation of rights in a report (RLS) is covered on the BI side: BI matrix — RLS Security and Access; code security is in the SD matrix — Security.
What this theme measures#
- Axis: from ignoring sensitive data to privacy by design, proven and audited.
- Key indicator: share of datasets containing personal or sensitive data that are known, classified, and protected, and ability to respond to an erasure or access request within the legal deadline.
- Unit: % of classified datasets; processing time for a data subject request (in days); number of unjustified accesses detected.
The five levels#
| Level | Short name | Promise | Typical indicator (orders of magnitude) |
|---|---|---|---|
| 1 | Ignored | Data is available to those with database access; sensitivity is unknown. | No classification; access via shared accounts |
| 2 | Inventoried | We know what personal and sensitive data exists and where it is. | ≥ 80% of tables inventoried with “personal” flag |
| 3 | Controlled | Each processing activity has a purpose, retention period, minimal access, and record; data subject requests have a process. | Up-to-date record; data subject request processed < 30 days |
| 4 | Proven | Protection is technically verified (encryption, masking, logging) and erasure is tested end-to-end. | Erasure verified across all environments; quarterly access review |
| 5 | By design | Privacy is integrated from scoping onward; data is anonymized or pseudonymized by default in secondary uses. | Non-personal test data; external audits with no major findings |
Milestones by level#
| ID | Milestone | Verifiable evidence |
|---|---|---|
| PD-SEC-1.1 | Database access is personal, not shared. | Account review with no generic read account on personal data. |
| PD-SEC-1.2 | Passwords and secrets do not appear in clear text in scripts or repositories. | Secret pattern scan in repository returns no results. |
| PD-SEC-1.3 | Backup is encrypted or stored in an access-controlled location. | Configuration verified. |
| PD-SEC-1.4 | The DPO / security contact is known by the team. | Team can name the contact. |
| PD-SEC-2.1 | An inventory exists of tables and columns containing personal data. | List of personal columns (name, email, geolocation, user ID). |
| PD-SEC-2.2 | Any sensitive data (health, union membership, biometric…) is identified separately. | Explicit “none” statement or list with justification. |
| PD-SEC-2.3 | The purpose of each personal dataset is written. | “Purpose” column in the inventory. |
| PD-SEC-2.4 | Non-production environments do not contain real personal data, or are protected like production. | Test environment controls (see DOP). |
| PD-SEC-3.1 | A record of processing activities (Art. 30) is kept up to date for the data scope. | Dated record, reviewed with the DPO. |
| PD-SEC-3.2 | Minimization is applied: only necessary columns are loaded. | Column-by-column review justifying each personal data item. |
| PD-SEC-3.3 | A retention period is defined and applied (purge or anonymization). | Purge procedure executed at least once with trace. |
| PD-SEC-3.4 | A process handles access and erasure requests with owner and deadline. | Mock request processed end-to-end. |
| PD-SEC-4.1 | Access to personal data is logged and reviewed on a fixed schedule. | Access log and quarterly review report. |
| PD-SEC-4.2 | Masking or pseudonymization is applied to uses that do not require identity. | Masked view or column in exposure layers. |
| PD-SEC-4.3 | Erasure of a person is tested in the datamart, backups, extracts, and reports. | Documented erasure test across all stores. |
| PD-SEC-4.4 | A data protection impact assessment (Art. 35) is performed for high-risk processing. | Signed DPIA or reasoned decision of non-necessity. |
| PD-SEC-5.1 | Privacy is reviewed from the scoping stage of each new data product. | “Personal data” section in the scoping sheet (VAL). |
| PD-SEC-5.2 | Secondary uses (testing, analytics, AI) rely on anonymized or synthetic data. | Verification of test datasets and training corpora. |
| PD-SEC-5.3 | A data breach exercise is carried out (detection, notification within GDPR’s 72-hour window). | Exercise report with measured timelines. |
| PD-SEC-5.4 | An independent audit (internal or external) confirms compliance with no major findings. | Audit report and closed action plan. |
Detailed reading by level#
🟢 Level 1 — Ignored#
- Signs: one shared account for tools; Excel extracts with names are circulated; password is in a script.
- Gain: apparent simplicity.
- Does not guarantee: anything you can prove to an auditor or to a person exercising their rights.
- Difficulty: 1/5 · Effort: 1/5.
🟢 Level 2 — Inventoried#
- Signs: a table of personal columns; purpose is documented; test environments are handled separately.
- Gain: we know what we are talking about; first foundation for a record.
- Does not guarantee: implementation of measures or ability to erase.
- Difficulty: 2/5 · Effort: 2/5.
🟡 Level 3 — Controlled#
- Signs: record, minimization, retention period, rights process tested with a mock request.
- Gain: a defensible posture; the DPO has supporting elements.
- Does not guarantee: technical completeness (forgotten copies, extracts, report caches).
- Difficulty: 3/5 · Effort: 3/5.
An erasure request for a sales rep leaving the company. At level 3, the process exists; at level 4, we test that no personally identifiable trace remains: datamart, staging tables, backups (documented expiration delay), shared extracts, semantic model caches. The most frequent omission: the staging table and the copy of the test environment; hence PD-SEC-4.3, which requires all stores.
🟡 Level 4 — Proven#
- Signs: reviewed access log; columns masked by default; erasure tested across all stores; DPIA for risky processing.
- Gain: compliance becomes demonstrable, not just declared.
- Does not guarantee: resistance to a determined attacker (see SD — Security); GDPR and security overlap but are not identical.
- Difficulty: 4/5 · Effort: 4/5.
-- Pseudonymization of an identity column in the exposure layer (T-SQL)
CREATE VIEW [expo].[Utilisateur] AS
SELECT USR_ID,
CONVERT(CHAR(64), HASHBYTES('SHA2_256', CONCAT(USR_EMAIL, (SELECT SEL FROM [sec].[Parametre]))), 2) AS USR_EMAIL_PSEUDO,
USR_PROFIL, USR_REGION
FROM [dim].[Utilisateur];
-- The salt is kept outside the view, with restricted access; pseudonymized data is still personal data under GDPR.
🔴 Level 5 — By design#
- Signs: privacy is included in the scoping sheet; tests use synthetic data; a breach exercise has taken place.
- Gain: compliance stops being a blocker and becomes a product attribute.
- Does not guarantee: absence of incidents; level 5 reduces probability and impact, not residual risk.
- Difficulty: 5/5 · Effort: 5/5.
Partial achievement and rating#
Evaluate on each dataset containing personal data (or, failing that, the three most sensitive). A milestone is worth 1 if all relevant datasets meet it, 0.5 if the majority do, 0 otherwise. A milestone without evidence is worth 0: compliance must be demonstrated.
A “partial 5”: privacy appears in new product scoping (5.1 = 1), test datasets are anonymized for two out of five domains (5.2 = 0.5), a tabletop breach exercise was done (5.3 = 0.5), no external audit has taken place (5.4 = 0).
Pseudonymizing while thinking it is anonymized: an email hash is still personal data (re-identifiable by correlation). Symptom: “there is no more personal data.” Cause: confusion between pseudonymization and anonymization. Remedy: treat the output as personal data unless the DPO states otherwise.
Erasure that forgets copies: staging, backups, Excel extracts, caches. Remedy: map stores (see MET, lineage) and define backup expiration compatible with response deadlines.
Data security and report security mixed up: perfect RLS does not prevent full export from the database. Each layer must be protected.
Moving to the next level#
Possible means (optional)
| Transition | Possible levers |
|---|---|
| 1 → 2 | Scan columns by names and patterns (email, phone, name); have owners validate (GOV). |
| 2 → 3 | Build the record with the DPO; remove unnecessary personal columns; write the rights procedure. |
| 3 → 4 | Access logging; masked views; cross-cutting erasure test; DPIA. |
| 4 → 5 | Synthetic or anonymized data for testing; breach exercise; external audit. |
Cross-cutting pitfalls: (1) False positive — an up-to-date record disconnected from technical reality: compare it with the column inventory. (2) Goodhart — targeting “100% classified tables” leads to default “internal” classification; audit a sample. (3) Security through obscurity — data masked in the report but readable in the model.
It helps detect personal columns through profiling, draft a record, and generate synthetic data. Major risk: personal data must not be sent to an unauthorized AI service; verify contract, region, and retention before any use. AI replaces neither the DPO nor lawfulness decisions.
See also#
- Same matrix: 02 Governance and Organization · 05 Modeling and Architecture · 12 Metadata, Lineage, and Documentation · 10 Operations and Support · README
- Other matrices: SD — Security · BI — RLS Security and Access · PI — Risk Management (RSK) · BI — Governance, Catalog, and Self-Service
- Practice: Methods Specific to Data Projects · SQL Server in SaaS — Challenges and Pitfalls · OneLake + SaaS Mobile Apps: Challenges and Pitfalls · AI for Project Management (General, Then Data)
- Glossary · Rating
✻ Written by Claude Sonnet 5.5