Traceabilitymatrix¶
Doel en leeswijzer¶
Deze matrix koppelt de oorspronkelijke criteriaclusters aan een standaard of aanvullende
kwaliteitsclassificatie. Concept betekent niet vastgesteld CIZ-beleid. Detail-ID’s
verwijzen naar de toetsingscatalogus, die per ID de
actuele normbron en bewijsvorm aanwijst.
De classificaties in deze herkomstmatrix beschrijven het type oorspronkelijk criterium; “Ontwikkelstandaard” betekent hier niet dat een standaard formeel is vastgesteld. Waar de catalogus een open normvoorstel noemt, staat de oorspronkelijke afspraak in het normvoorstellenregister. Een gedeeltelijke STD-koppeling dekt uitsluitend het genoemde deelgebied. Deze matrix introduceert geen extra eisen en is geen tweede normbron.
De matrix traceert opdrachtcriteria en kopieert geen controls uit BIO, ISO/IEC 27001/27002 of NEN 7510. Voor beleids- en normtraceerbaarheid wordt verwezen naar het kaderregister en, na CIZ-validatie, naar de canonieke controlregistratie.
| Oorspronkelijk criterium | Classificatie en bestemming | Motivatie / status |
|---|---|---|
| UTC-timestamps; lokale conversie in presentatielaag; ISO 8601; UTF-8; impact API/database/log/event/UI | STD-0001 | Interoperabiliteitsstandaard; bestaande CIZ-/ketenformaten Te valideren. |
| Expliciete API-versioning; semantisch wijzigingsmodel; breaking = major; backward compatibility | STD-0002 | Contract- en lifecycle-standaard. |
| Tijdelijk minimaal twee API-versies | STD-0002 + NFR-DOC-03/09 | Conditionele norm; termijn/uitvoerbaarheid Te valideren. |
| Deprecation en breaking-change-documentatie | STD-0002 + NFR-DOC-01/04/09 | Lifecycle-afspraak met releasebewijs. |
| RFC 9457-foutresponses | STD-0002 | Voorkeursbasis; CIZ-brede extensies/vaststelling Te valideren. |
| Producent-/consumentverantwoordelijkheden | STD-0002 | Onderdeel contractgovernance. |
| Beveiligde/geauthenticeerde kanalen; encryptie van alle persistente gegevens en kopieën | STD-0003 | Organisatiebrede baseline met aantoonbare uitzonderingsroute. |
| HSM-backed CMK als voorkeursrichting; centraal sleutel-/certificaatbeheer; crypto-agility; geen hardcoding; rotatie | STD-0003 + NFR-CODE-05 | Securitystandaard, Azure-profiel en ontwikkelcontrole. |
| Toegangsbeperking; authenticatie/autorisatie | STD-0003 + NFR-SEC-09 | Securitystandaard en toetsbaar toegangsbeheer. |
| Scheiding technische, security- en auditlogs | STD-0004 | Verschillende doelen, toegang, retentie en integriteit. |
| Centrale verzameling; primaire verwerking niet verstoren | STD-0004 | Operationele norm met expliciete fail-closed uitzondering. |
| Timestamp, correlation ID, actor, actie, resultaat | STD-0004 | Risicogestuurd schema; naam/e-mail bewust niet verplicht. |
| Dataminimalisatie; privacy; retentie | STD-0004 + NFR-SEC-01/02/03/08 | Accountability versus privacy expliciet afgewogen; termijnen Te valideren. |
| Onveranderbaarheid; roltoegang; SIEM/SOC; leveranciers; detectie | STD-0004 + NFR-SEC-09 | Operationele controls; bestaande voorzieningen Te valideren. |
| Minimale packages en noodzakelijke dependencies | STD-0005 | Supply-chain- en deploymentnorm. |
| Code/configuratiescheiding; environment variables; secret manager | STD-0005 | Drie configuratieklassen expliciet onderscheiden. |
| Herbruikbaar artefact; geen grote omgevingswijzigingen | STD-0005 | Build-once/promote-norm. |
| Declaratieve versiebeheerbare scripts; reproduceerbaarheid; rollback/herstel | STD-0005 + NFR-DOC-08 | Deliverystandaard plus releasebewijs. |
| Containerized deployment en voorwaarden | STD-0006 | Geschiktheidskader; containerisatie geen doel op zichzelf. |
| Health/readiness/liveness; graceful lifecycle; externe state; resources | STD-0006 | Container-runtimecontract. |
| Horizontale/verticale schaal; productneutrale orchestrator | STD-0006 + STD-0009 | Platforminrichting respectievelijk workloadgedrag; product Te valideren. |
| Centrale ingress/egress, minimale publieke IP-set, private verbindingen, API-gateway en WAF | STD-0010 | Platformbrede netwerkstandaard en uitwerking van het Zero Trust-principe. |
| Machine-readable HTTP health | STD-0007 | Waar HTTP passend is; acceptatietest vereist. |
| Metrics, logs, traces; OpenTelemetry/open standaard | STD-0007 | Observabilitystandaard; OpenTelemetry voorkeursrichting Te valideren. |
| Correlation/distributed tracing; dependencies; dashboards/alerts | STD-0007 | Operationeel model. |
| Time-outs, retries, circuit breakers; SLO-risico; fallback | STD-0007 + STD-0009 | Zichtbaarheid in STD-0007, gedrag in STD-0009. |
| Beperkte performance-impact; CIZ-/leveranciersverantwoordelijkheden | STD-0007 | Budgettering en taakverdeling; concrete waarden/rollen Te valideren. |
| Modules, versieerbare componenten, interfaces, cohesion/coupling | STD-0008 | Applicatiestructuurstandaard. |
| Scheiding van data, functionaliteit en processen; gegevensportabiliteit en open semantische contracten | STD-0008 | Uitwerking van CIZ-architectuurprincipes 1 en 3. |
| Frontend/backend waar passend; geen ongecontroleerde directe DB-koppelingen | STD-0008 | Conditionele grens, geen universele fysieke splitsing. |
| Vervangbaarheid, testbaarheid, onderhoudbaarheid | STD-0008 | Kwaliteitsdrivers en verificatie. |
| Onafhankelijke deployment waar waarde; geen microservicesplicht | STD-0008 | Bewuste begrenzing tegen onnodige distributie. |
| Stateless sessies; horizontaal/verticaal schalen; geen node-afhankelijkheid | STD-0009 | Resilience- en schaalnorm met stateful uitzonderingen. |
| Begrensde retries/back-off; circuit breakers; fallback; idempotentie | STD-0009 | Toetsbaar failure-behavior. |
| SLO in gevaar; schaal-/resiliencetests; kosten/complexiteit | STD-0009 + NFR-TEST-01/02/03 | Technische norm plus verificatie. |
| Feedback bij wachttijd; begrijpelijke foutmeldingen | NFR-UX-01/02 | UX- en acceptatiecriteria, geen zelfstandig architectuurbesluit. |
| Geen gevoelige details; stabiele foutcodes | NFR-UX-02/03 + STD-0002/STD-0004 | UX-eis met fout- en logcontracten. |
| Externalisatie teksten/vertalingen | NFR-UX-04 | Ontwikkel-/UX-standaard, geen ADR. |
| Verstoringcommunicatie; toegankelijkheid | NFR-UX-05/06 | Operationele/UX- en acceptatie-eisen; toepasselijk kader Te valideren. |
| Scheiding gebruikersmelding/technische logging | NFR-UX-07 + STD-0004 | Acceptatiecriterium op loggingstandaard. |
| Changelog; versiegebonden docs; majors; breaking changes | NFR-DOC-01/02/03/04 | Documentatie- en release-eisen. |
| Configuratie-, architectuur-, platform/browser-, deployment- en systeemeisendocs | NFR-DOC-05/06/07/08 | Documentatie-/test-/release-eisen. |
| Releasebeleid; troubleshooting/support; actualisatie; formaat/detail | NFR-DOC-09/10/11/12 | Proces- en documentatie-eisen. |
| Licentie-informatie en componentlicenties | NFR-DOC-13 | Compliance-/release-eis. |
| Engels code/namen/comments tenzij standaard anders bepaalt | NFR-CODE-01 | Ontwikkelstandaard; CIZ-conventie Te valideren. |
| Betekenisvolle comments/waarom; beschrijvende namen | NFR-CODE-02/03 | Ontwikkelstandaard. |
| Vast commentaarpercentage | Niet overgenomen | Geen betrouwbare onderhoudbaarheidsmaat; stimuleert niet-betekenisvol commentaar. |
| Style guides; geen hardcoded constanten; dead code verwijderen | NFR-CODE-04/05/06 | Ontwikkelstandaarden. |
| Statische analyse; dependency-/vulnerabilityscan | NFR-CODE-07/08 | CI- en securitytestcriteria. |
| Unit/component-, integratie- en acceptatietests | NFR-TEST-01/02/03 | Testcriteria. |
| Zichtbare CI-resultaten; machine-readable resultaten | NFR-TEST-04/07 | Test-/acceptatiecriteria. |
| Coverage als indicator | NFR-TEST-05 | Geen zelfstandig kwaliteitsbewijs. |
| 75% unit/component en 50% acceptance coverage | NFR-TEST-06 | Alleen mogelijke startwaarden, Te valideren; acceptance coverage eerst definiëren. |
| PR/review; reviewbesluiten | NFR-TEST-08/09 | Review- en documentatie-eisen. |
| Automatische securitycontroles; periodieke testdrempelreview | NFR-TEST-10/11 | Securitytest- en governance-eisen. |
| Line versus functionele dekking; kritieke/gegenereerde code; mutation/branch/risico | NFR-TEST-05/06 | Nuancering voor risicogestuurde teststrategie. |
| Privacy by design; risicoanalyse/DPIA | NFR-SEC-02/03 | Ontwerp- en governance-eisen, ondersteund door ISMS-risicobenadering. |
| Kwetsbaarheidscontrole; secret scanning; SCA | NFR-SEC-04/05/06 | Geautomatiseerde securitytestcriteria. |
| Auditability; bewaartermijnen; toegang gevoelige data/logs | NFR-SEC-07/08/09 | Security-/privacy-eisen. |
| Gebruik/interactie: support, wachttijd, toegankelijkheid, vertalingen, verstoringen | NFR-UX-01 t/m 06 | Aanvullende kwaliteitscriteria. |
Brontraceerbaarheid¶
Het aangeleverde ISMS-beleid onderbouwt uitsluitend de algemene drivers en governance: bescherming van vertrouwelijkheid/integriteit/beschikbaarheid, continuiteit, risicobeoordeling, toegangsbeheer, incidentrespons, leveranciersmaatregelen, monitoring, audits en continue verbetering. Het noemt BIO, ISO 27001/27002 en NEN 7510. Geen van de technische detailkeuzes hierboven wordt als reeds vastgesteld CIZ-besluit aan die bron toegeschreven.