Jira - Controleprogramma

Doel

Periodieke controle op de werking van het ISMS via de controlepunten in de tabel hieronder. De definitie staat in controleprogramma.yaml in deze map; de uitvoering loopt in het Jira-project ISMS.

Werkwijze

1. De definitie van het programma (controles, interval, ankermaand, eigenaar, beschrijving) staat in controleprogramma.yaml en wordt via pull request beheerd. Het validatiescript controleert het bestand.
2. Op de eerste van elke maand maakt de GitHub Action controleprogramma.yml voor elke controle waarvan de volgende ronde binnen twee maanden valt een Jira-ticket aan, tenzij dat ticket al bestaat. Herkenning gaat op de labels controleprogramma, C-xx en ronde-JJJJ-MM. Een run is ook handmatig te starten met gh workflow run controleprogramma.yml.
3. Tickets hangen onder de epic “Controleprogramma” en krijgen als due date de laatste dag van de rondemaand. Controles met deeltaken (C.01, C.26) krijgen die als subtaken. Een gemiste controle blijft als verlopen ticket zichtbaar; er wordt niets stilletjes overgeslagen.
4. De uitvoerder vult het verslag in het ticket in: datum, uitvoerder, resultaat, actiepunten. Afwijkingen worden losse tickets onder de epic “Certificering 2027” of een opvolger, gelinkt aan het controleticket.
5. Verandert de YAML (beschrijving, uitvoerder, due date) terwijl er al tickets voor de ronde bestaan, dan start de IB-coördinator de workflow handmatig met de optie bijwerken. Alleen tickets die nog niet gestart zijn (Backlog, Triage, Selected for Development) en waarvan het verslag nog leeg is, worden opnieuw gevuld: titel, beschrijving en due date. Status, assignee, comments en subtaken blijven staan; een ticket waarin iemand het verslag al is begonnen in te vullen wordt overgeslagen en gemeld. De maandelijkse run doet dit nooit. Elke run logt eerst met welk Jira-account hij werkt en hoeveel controleprogramma-tickets dat account ziet; met bijwerken stopt de run als dat er nul zijn, zodat een account zonder rechten geen dubbele tickets aanmaakt.

Eigenaar en uitvoerder

Elke controle heeft een owner-rol en een uitvoerder. De owner is verantwoordelijk voor het onderwerp en voor het oplossen van afwijkingen; de uitvoerder (de assignee van het ticket) doet de controle. Die twee zijn bewust vaak verschillende personen, zodat niemand alleen zijn eigen werk beoordeelt: de HR-dossiers (C.17) worden niet door de HR-manager nagelopen en de firewalls (C.09) niet door de DevOps Lead. De eigenaar-rol staat in de ticketbeschrijving; wie uitvoert staat alleen in controleprogramma.yaml (veld assignee) en in Jira, niet in de ISMS-documentatie. Zonder expliciete uitvoerder gaat het ticket naar de owner-rol.

Controlesoorten

Soort	Beschrijving	Voorbeeld
Toetsen	Test of bespreking om naleving te controleren	Technische test, interview met eigenaar
Doornemen	Procedure walkthrough met betrokkenen	Interne audit van een proces
Meten	Nagaan of maatregelen effect hebben	KPI-meting, trendanalyse

Controlepunten

Gegenereerd uit controleprogramma.yaml; niet met de hand bewerken.

Code	Onderwerp	Soort	Controls	Interval	Owner
C.01	Hoofdstukken ISMS	doornemen	clausule 4-10, controls, Z1-Z8	12 mnd	IB-coördinator
C.02	Behaalde IB-doelstellingen	meten	6.2, 9.1	12 mnd	Directie
C.03	Toepassing IB-aspecten in projectproces	toetsen	5.08, 5.12, 5.13, 8.26, 8.29	12 mnd	Project Manager
C.04	Beheersing uitgegeven middelen	toetsen	5.09, 5.10, 5.11, 7.10, 7.14, 8.10	12 mnd	HR-manager
C.05	Uitvoering in/uit-dienstproces	toetsen	6.01, 6.05, 5.16	12 mnd	HR-manager
C.06	Toepassing werkplekbeleid	toetsen	7.07, 8.01, 7.09, 7.13, 8.07	12 mnd	IB-coördinator
C.07	Actualiteit autorisatie-overzichten	toetsen	5.15, 5.18, 8.02, 8.03, 8.04, 8.05, 7.02	12 mnd	IB-coördinator
C.08	Effectiviteit back-upvoorzieningen	meten	8.13	3 mnd	DevOps Lead
C.09	Effectiviteit firewalls en netwerk	meten	8.20, 8.21, 8.22	12 mnd	DevOps Lead
C.10	Toepassing secure engineering principles	toetsen	8.25, 8.27, 8.28, 8.31	6 mnd	IB-coördinator
C.11	Beheersing IB-incidenten	doornemen	5.24, 5.25, 5.26, 5.27, 5.28, 6.08	12 mnd	IB-coördinator
C.12	Beoordeling en test continuïteitsplan	doornemen	5.29, 5.30, 8.06, 8.14	12 mnd	IB-coördinator
C.13	Beveiliging in overeenkomsten en leveranciersbeoordeling	doornemen	5.19, 5.20, 5.21, 5.22, 5.23	12 mnd	Directie
C.14	Beoordeling technische naleving	meten	5.36, 8.08, 8.09, 8.24, 5.32	6 mnd	DevOps Lead
C.15	Uitvoering bewustwordingsprogramma	meten	6.03	12 mnd	IB-coördinator
C.16	Uitvoering logging en change management	toetsen	8.15, 8.19, 8.32	12 mnd	DevOps Lead
C.17	Arbeidsovereenkomst en HR-dossiers: geheimhouding	toetsen	6.02, 6.06	12 mnd	HR-manager
C.18	Jaarlijkse vulnerability assessment eigen infrastructuur	meten	8.08, 8.29	12 mnd	DevOps Lead
C.19	Cross-repo dependency vulnerability scan	meten	8.08	1 mnd	DevOps Lead
C.20	Maandelijkse KPI-verzameling	meten	9.1	1 mnd	IB-coördinator
C.21	Kwartaalrapport aan directie	meten	9.1	3 mnd	IB-coördinator
C.22	Security log review	toetsen	8.15, 8.16	1 mnd	DevOps Lead
C.23	Directiebeoordeling	doornemen	9.3, 10.1, 10.2, 7.4	6 mnd	Directie
C.26	NEN7510 zorgspecifieke maatregelen	doornemen	Z1-Z8	12 mnd	IB-coördinator
C.27	Privacy: verwerkingsregister en DPIA’s	doornemen	5.34	12 mnd	IB-coördinator
C.28	Risicobeoordeling actualiseren	doornemen	6.1	12 mnd	IB-coördinator

Jira

• Epic: Controleprogramma (ISMS-370)
• Filter lopende ronde: project = ISMS AND labels = controleprogramma AND statusCategory != Done
• Verbeteracties: epic Certificering 2027 (ISMS-323)

Titelformaat: C.08 Effectiviteit back-upvoorzieningen [8.13].

Relatie met monitoring

Dit controleprogramma is de operationele uitvoering van clausule 9.1 (Monitoring en meting). Zie 09-evaluatie/9.1-monitoring.md voor de KPI’s en rapportage.

Relatie met interne audit

Het controleprogramma is aanvullend op de interne audit (clausule 9.2). De controles richten zich op de dagelijkse werking; de interne audit beoordeelt het ISMS als geheel. Zie 09-evaluatie/9.2-interne-audit/9.2.1-programma.md.