|
| 1 | +<!-- |
| 2 | + - SPDX-FileCopyrightText: 2026 Conduction B.V. <info@conduction.nl> |
| 3 | + - SPDX-License-Identifier: EUPL-1.2 |
| 4 | + --> |
| 5 | + |
| 6 | +# BIO compliance assessment |
| 7 | + |
| 8 | +Adds the Dutch government security/privacy compliance stack on top of the |
| 9 | +existing GEMMA compliance model: a seedable **BIO 2.0 measures** catalog, |
| 10 | +per-application **BBN level** and **DPIA** tracking, a reference to the |
| 11 | +organisation's **register van verwerkingen** entry, catalog filters, a |
| 12 | +per-organisation **BIO coverage report**, and a declarative notification for |
| 13 | +overdue DPIA reviews. |
| 14 | + |
| 15 | +Specifications: |
| 16 | +[`openspec/specs/bio-compliance-assessment/spec.md`](../../openspec/specs/bio-compliance-assessment/spec.md) |
| 17 | +(new capability) and the `module-compliance-assessment` MODIFIED delta |
| 18 | +(BIO-measure column source on the compliance matrix). |
| 19 | + |
| 20 | +## Why this extends `compliancy`, not a new schema |
| 21 | + |
| 22 | +BIO measure compliance is asserted through the **same** `compliancy` record |
| 23 | +model already used for GEMMA standards (`module ↔ standaardversie`, |
| 24 | +evidence, verified/claimed). `compliancy` gains one more optional relation, |
| 25 | +`bioMaatregel`, parallel to `standaardversie`. A record links a module to |
| 26 | +**exactly one** of the two relations — never both (a record carrying both is |
| 27 | +flagged as a data-quality issue and excluded from every matrix rather than |
| 28 | +matched to either column). This reuses the entire evidence/verified-claimed |
| 29 | +mechanism and the matrix mapper instead of forking a parallel "BIO |
| 30 | +assessment" object. |
| 31 | + |
| 32 | +## The BIO measures catalog |
| 33 | + |
| 34 | +A `bioMaatregel` object is one BIO 2.0 measure: `code`, `naam`, |
| 35 | +`omschrijving`, `thema`, `bioVersie`, the applicable `bbnNiveau`(s), and a |
| 36 | +`bron` reference to the published measure list. It is a publicly readable |
| 37 | +reference catalog (`authorization.read: ["public"]`), seeded on |
| 38 | +install/upgrade from `lib/Settings/softwarecatalogus_register.json`'s |
| 39 | +`x-openregister.seedData.objects.bioMaatregel` array — the same |
| 40 | +seed-and-reimport pattern the GEMMA `element` catalog already uses, so |
| 41 | +re-running the `InitializeSettings` repair step is idempotent (upsert by |
| 42 | +`slug`). |
| 43 | + |
| 44 | +Browsable via **BIO measures** (`BioMaatregelen` index / `BioMaatregelDetail` |
| 45 | +detail page), which lists every compliance claim referencing the measure — |
| 46 | +the same "claims for this X" pattern `StandaardDetail` already uses. |
| 47 | + |
| 48 | +## Application-level fields |
| 49 | + |
| 50 | +`module` gains six optional fields (no `required` change, so existing |
| 51 | +objects stay valid without migration): |
| 52 | + |
| 53 | +| Field | Type | Notes | |
| 54 | +|---|---|---| |
| 55 | +| `bbnLevel` | enum `BBN1`/`BBN2`/`BBN3` | `facetable: true` — drives the catalog filter and the coverage report | |
| 56 | +| `dpiaStatus` | enum `not required`/`required`/`executed` | | |
| 57 | +| `dpiaDate` | date | Meaningful only when `dpiaStatus` is `executed`; not enforced at write time | |
| 58 | +| `dpiaVolgendeBeoordeling` | date | Next DPIA review due date; drives the overdue notification | |
| 59 | +| `dpiaDocumentRef` | string (NC Files reference) | Link-don't-store, mirroring `compliancy.bewijsReferentie` | |
| 60 | +| `verwerkingsregisterRef` | string (URL or identifier) | Reference only — this change does not model the register van verwerkingen itself | |
| 61 | + |
| 62 | +These render on the `ModuleDetail` page's data widget alongside the |
| 63 | +application's other fields, and on the `Modules` index/catalog listing. |
| 64 | + |
| 65 | +## Catalog filters |
| 66 | + |
| 67 | +The `Modules` index page's quick filters include `BBN1`/`BBN2`/`BBN3` and a |
| 68 | +compound **"Without DPIA (BBN2+)"** filter. The compound filter is expressed |
| 69 | +as two bare-array IN-clauses — |
| 70 | +`{"bbnLevel": ["BBN2", "BBN3"], "dpiaStatus": ["not required", "required"]}` |
| 71 | +— rather than a `{dpiaStatus: {ne: "executed"}}` operator object: the |
| 72 | +frontend's `useObjectStore.buildQueryString` JSON.stringifies plain-object |
| 73 | +filter values into a single GET query-string value, which OpenRegister's |
| 74 | +`MagicSearchHandler` never `json_decode`s back into an array (only |
| 75 | +bracket-repeated `field[]=` array params survive as a real PHP array on |
| 76 | +that path), so an operator object would silently no-op. The IN-list only |
| 77 | +matches the two explicit "not executed" enum values — a module with |
| 78 | +`dpiaStatus` entirely unset is not caught by this quick filter (SQL `IN()` |
| 79 | +never matches `NULL`), though the catalog's DPIA column still shows it as |
| 80 | +unset for a human reviewer. |
| 81 | + |
| 82 | +## BIO coverage report |
| 83 | + |
| 84 | +Extends the existing `ComplianceMatrixView` (`src/views/ComplianceMatrixView.vue`, |
| 85 | +`src/utils/complianceMatrix.js`) rather than adding a new page. A radio |
| 86 | +switch picks the column source — **Standards** (`standaardversie`) or |
| 87 | +**BIO measures** (`bioMaatregel`) — and, in the BIO scope, each row also |
| 88 | +shows the module's BBN level and DPIA status. An organisation picker scopes |
| 89 | +the rows to that organisation's in-use applications (`gebruik.afnemer` → |
| 90 | +`gebruik.module`); applications with no BBN level, DPIA data, or BIO measure |
| 91 | +compliance are still listed, rendered as "none" / "Not set" — never omitted. |
| 92 | +The selection (column source, selected columns, organisation) is encoded in |
| 93 | +the URL so a comparison is shareable. |
| 94 | + |
| 95 | +`complianceMatrix.js`'s `partitionCompliancy()` / `buildComplianceMatrix()` / |
| 96 | +`buildOrganisationCoverage()` all take a `columnSource` parameter |
| 97 | +(`COLUMN_SOURCE.STANDAARDVERSIE` or `COLUMN_SOURCE.BIO_MAATREGEL`) so the |
| 98 | +BIO-measure matrix reuses the exact same mapper as the standards matrix — no |
| 99 | +second cell-state computation exists. |
| 100 | + |
| 101 | +## Overdue DPIA notification |
| 102 | + |
| 103 | +`module` declares a `dpia-review-overdue` rule in the canonical |
| 104 | +`x-openregister-notifications` dialect (ADR-031 — declarative, no bespoke |
| 105 | +PHP notification service): |
| 106 | + |
| 107 | +```json |
| 108 | +{ |
| 109 | + "trigger": { |
| 110 | + "type": "scheduled", |
| 111 | + "intervalSec": 86400, |
| 112 | + "filter": { |
| 113 | + "dpiaStatus": { "operator": "equals", "value": "executed" }, |
| 114 | + "dpiaVolgendeBeoordeling": { "operator": "withinNext", "value": "P0D" } |
| 115 | + } |
| 116 | + }, |
| 117 | + "channels": ["nc-notification", "email"], |
| 118 | + "recipients": [ |
| 119 | + { "kind": "groups", "groups": ["software-catalog-admins"] }, |
| 120 | + { "kind": "object-acl", "permission": "manage" } |
| 121 | + ], |
| 122 | + "subject": { |
| 123 | + "nl": "DPIA-beoordeling verlopen: {{naam}} (uiterlijk {{dpiaVolgendeBeoordeling}})", |
| 124 | + "en": "DPIA review overdue: {{naam}} (due {{dpiaVolgendeBeoordeling}})" |
| 125 | + } |
| 126 | +} |
| 127 | +``` |
| 128 | + |
| 129 | +`withinNext` with a zero-day window (`P0D`) reads as "due on or before |
| 130 | +today" — the same trigger/filter shape already proven in this register by |
| 131 | +`contract`'s `contract-expiry` and `gebruik`'s `phaseout-approaching` rules, |
| 132 | +so no new engine behaviour is assumed. |
| 133 | + |
| 134 | +## Fixed along the way |
| 135 | + |
| 136 | +- The `Modules`/`Diensten` navigation pages were, on disk before this |
| 137 | + change resumed, mid-replacement: the pre-existing `type: custom` |
| 138 | + `FacetedCatalogIndexView` pages (proposed by the still-open |
| 139 | + `gemma-faceted-search` change) point at a component that was never |
| 140 | + registered in `customComponents.js` — a pre-existing dangling reference. |
| 141 | + An earlier pass of this change had silently deleted `Diensten` |
| 142 | + (nav entry and page) while replacing `Modules`; both are restored/kept |
| 143 | + here — `Modules` becomes a working `type: index` page (needed for the |
| 144 | + BBN/DPIA fields and filters), `Diensten` is left exactly as it was |
| 145 | + (broken, pending `gemma-faceted-search`, out of scope for this change). |
| 146 | +- `organisation-merge`'s Organisaties index filter had the same |
| 147 | + `{"$ne": ...}` defect this change's own compound filter would have |
| 148 | + introduced (see docs/features/organisation-merge.md) — fixed to the |
| 149 | + working IN-list shape while investigating the operator dialect. |
| 150 | + |
| 151 | +## Out of scope |
| 152 | + |
| 153 | +- Automated BIO evidence collection. |
| 154 | +- ISMS workflows beyond the DPIA review date. |
| 155 | +- NIS2 incident reporting, audit certification flows (ENSIA, DigiD). |
| 156 | +- Modelling the register van verwerkingen itself (reference only). |
| 157 | +- Computing `bbnLevel` or `dpiaStatus` automatically — both are user-entered. |
| 158 | + |
| 159 | +## Screenshots |
| 160 | + |
| 161 | +Not captured in this change — the implementing session had no live |
| 162 | +Nextcloud instance to drive Playwright against without touching the shared |
| 163 | +dev environment (out of bounds for this change). Follow-up: capture the |
| 164 | +Modules BBN/DPIA fields, the BIO measures catalog, the BIO coverage report, |
| 165 | +and the DPIA filter per ADR-010 once verified against a running instance. |
0 commit comments