ADR Security Besluitvorming

Besluiten Die Niet Verdampen

Dit onderwerp werkt het best als praktisch kader: helder genoeg voor besluitvorming en concreet genoeg voor uitvoering.

In ADR Security Besluitvorming is het doel keuzes vastleggen die teams consistent en herhaalbaar kunnen uitvoeren.

Daarmee blijft dit hoofdstuk geen theorie, maar een bruikbaar kompas voor consistente uitvoering.

Directe maatregelen (15 minuten)

• Gebruik deze pagina om maatregelen te prioriteren en in backlog om te zetten.
• Koppel elke maatregel aan eigenaar, deadline en aantoonbaar bewijs.
• Herhaal periodiek op basis van risico, wijzigingen en incidentlessen.

Waarom dit telt

De kern van ADR Security Besluitvorming is risicoreductie in de praktijk. Technische context ondersteunt de maatregelkeuze, maar implementatie en borging staan centraal.

Waarom ADR’s voor security

Zonder ADR:

• verdwijnen argumenten na verloop van tijd;
• worden uitzonderingen “normaal”;
• ontbreekt auditspoor bij incidenten.

Met ADR:

• is trade-off transparant;
• blijft ownership duidelijk;
• kan je gecontroleerd herzien.

Wanneer is een security-ADR verplicht?

Maak altijd een ADR bij:

• nieuwe trust boundary;
• wijziging in identity- of privilege-model;
• uitzonderingen op baseline controls;
• keuze voor cryptografie/key management;
• onboarding van kritieke leverancier/component.

ADR-template (security)

Gebruik onderstaand format:

# ADR-XXX: [Titel]

## Context
- Welke businessdoelstelling en welke assets?
- Welke dreigingen en compliance-eisen spelen hier?

## Besluit
- Wat kiezen we precies?
- Scope, randvoorwaarden, geldigheidsduur.

## Overwogen alternatieven
- Optie A: ...
- Optie B: ...
- Waarom afgewezen/gekozen?

## Security-impact
- Confidentiality / Integrity / Availability impact
- Nieuwe risico's en mitigerende controls

## Detectie en bewijs
- Welke logs/metrics tonen effectiviteit?
- Welke tests of controles zijn verplicht?

## Governance
- Eigenaar
- Reviewdatum
- Expiratiedatum / herijking

Beslisregels voor kwaliteit

Een ADR is bruikbaar als:

• risico expliciet en meetbaar is beschreven;
• alternatieven zijn afgewogen;
• compensating controls zijn benoemd;
• review- en expiratie-data zijn opgenomen;
• eigenaar en besluitbevoegde zijn vastgelegd.

Voorbeeld: uitzondering op segmentatie

Context: legacy-systeem vereist tijdelijk brede netwerktoegang.
Goede ADR-keuze bevat minimaal:

• tijdsgebonden uitzondering;
• extra monitoring/alerting;
• beperking op bron-doel-combinaties;
• plan en deadline voor structurele oplossing.

Slechte keuze: “tijdelijk opengezet” zonder einddatum en zonder detectie.

Integratie in changeproces

Koppel ADR’s aan:

• change tickets;
• pull requests voor policy/config;
• risicoregister;
• maandelijkse architecture review.

Zo blijft security-besluitvorming geen documentoefening, maar onderdeel van delivery.

Samenvatting

ADR’s maken security-architectuur bestuurbaar. Niet de hoeveelheid documentatie telt, maar de kwaliteit van expliciete trade-offs, meetbaarheid en herijking.