Azure App Service: HTTP Request Logging Inschakelen

Wanneer App Service exemplaren geen HTTP logging gebruiken, ontbreekt feitelijk het primaire forensische spoor om afwijkend verkeer te onderscheiden van regulier gebruik. Security-analisten zien dan niet dat geautomatiseerde scripts binnen enkele seconden honderden paden zoals /admin, /.git of /owa proberen op te vragen, en zij missen brute-force patronen waarbij dezelfde identiteit tientallen malen een aanmeldpoging doet. Operationele teams blijven bovendien blind voor intermitterende 500-fouten, omdat zonder request ID, payloadkenmerken en responstijden niet kan worden aangetoond welke microservice of welke regionale schaalinstantie het probleem veroorzaakt. Voor compliance-audits onder BIO 12.04, ISO 27001 A.12.4 en CIS 9.10 moet een organisatie aantonen dat alle webtoegang wordt gelogd en zeven jaar kan worden teruggezocht; zonder HTTP logs is dat onmogelijk en bestaat het risico dat audits mislukken of dat incidentonderzoek stilvalt. Het ontbreken van deze logbron heeft ook impact op ketensamenwerking: gemeenten, waterschappen en rijksdiensten delen steeds vaker SaaS-componenten, en wanneer één partner geen webserver-logging heeft, kan een gezamenlijke dreigingsanalyse niet worden afgerond. Ten slotte maken dreigingsactoren juist gebruik van deze zichtbaarheidsgaten om SQL-injection, path traversal, credential stuffing en DDoS-verkenningen uit te voeren, omdat zij weten dat organisaties zonder gedetailleerde logs het onderscheid tussen storing en aanval niet tijdig zien.

Implementatie

Deze maatregel configureert de diagnostische instelling AppServiceHTTPLogs zodat aanvragen rechtstreeks naar een Log Analytics-werkruimte met passende retentie worden verzonden. De beheerder activeert de logcategorie via Azure Portal (Monitoring → Diagnostic settings), via ARM/Bicep templates of met het PowerShell-script in deze repository zodat alle App Services dezelfde configuratie krijgen. Vanuit Log Analytics kunnen KQL-query’s en waarschuwingen worden ingericht die bijvoorbeeld alle 500-fouten per abonnement visualiseren, volumepieken per IP-adres detecteren of correlaties leggen met Defender for Cloud signalen. Het proces omvat het selecteren van de juiste werkruimte, het toepassen van gestandaardiseerde naming conventions, het testen in een representatieve staging-sleuf en het documenteren van opslag- en bewaarkosten zodat begrotingen transparant blijven. Door deze configuratie consequent door te voeren ontstaat een reproduceerbaar en auditbaar dossier dat aansluit op de Nederlandse Baseline voor Veilige Cloud.

Vereisten

Voor het succesvol inschakelen van App Service HTTP logs moet elke betrokken webapplicatie draaien op een ondersteund App Service plan (Linux of Windows) met diagnostische instellingen beschikbaar binnen het abonnement. De beheerder inventariseert vooraf hoeveel productie-, acceptatie- en testinstanties worden geraakt, controleert of alle apps minimaal op .NET 6, Java 11, Python 3.10 of een vergelijkbare ondersteunde runtime draaien en valideert dat regionale redundantie is ingericht. Deze inventarisatie omvat ook de deployment slots, omdat logging per slot moet worden ingeschakeld om een volledige tijdlijn vast te leggen. Door deze technische basis helder te hebben, voorkomt de organisatie dat er achteraf uitzonderingen ontstaan die alsnog handmatig moeten worden opgelost.

Naast de technische randvoorwaarden zijn de juiste machtigingen cruciaal. Teams die deze maatregel uitvoeren hebben minimaal de rol Contributor op de App Service en Log Analytics workspace nodig, in combinatie met Monitoring Contributor voor het aanmaken van alertregels. Wanneer het beheer is uitbesteed aan een shared service center, moet er een expliciet change request liggen dat de scope en het onderhoudsvenster beschrijft zodat niemand tijdens productiepieken wijzigingen doorvoert. Identity governance vereist bovendien dat serviceprincipals die via pipelines werken een toegewezen managed identity hebben met least-privilege rechten, zodat audit trails exact kunnen tonen wie de logging heeft ingeschakeld.

Een Log Analytics-werkruimte met voldoende retentie vormt de derde pijler. Binnen de Nederlandse Baseline voor Veilige Cloud is zeven jaar bewaartermijn het uitgangspunt voor webtoegangslogs, waardoor de workspace minimaal 2555 dagen retentie moet hebben of de logs automatisch moeten worden geëxporteerd naar een Archival Storage account met lifecycle policies. Het network team verifieert of de workspace bereikbaar is via private endpoints of service tags zodat verkeer binnen het overheidsnetwerk blijft. Tevens wordt een kostenraming opgesteld waarin per werkruimte staat hoeveel gigabyte per dag wordt verwacht, welke commitment tiers nodig zijn en hoe deze kosten op de betrokken organisatieonderdelen worden doorbelast.

Operationeel gezien moet ook de observability-keten klaarstaan. Dat betekent dat KQL-queries, workbooks en alertregels al bestaan voordat logging wordt aangezet, omdat anders grote hoeveelheden data worden verzameld zonder dat iemand de signalen interpreteert. Het SOC bepaalt drempelwaarden voor brute-force detectie, volumepieken en mislukte requests, terwijl het ontwikkelteam definieert welke request headers en correlation IDs nodig zijn om applicatiefouten te herleiden. Tevens moet er capaciteit zijn op de bestaande SIEM of SOAR om deze logs te verwerken; als Sentinel rulesets bijvoorbeeld nog niet bestaan, moet dat onderdeel van het werkpakket zijn.

Tot slot zijn governance en documentatievereisten standaard onderdeel van de voorbereidingen. Elke wijziging wordt vastgelegd in het centrale configuratieregister, inclusief koppeling naar architectuurtekeningen, risicodossiers en BIO-controles. Supportteams ontvangen een update van hun runbooks waarin staat hoe HTTP logs kunnen worden geraadpleegd tijdens incidenten en hoe logongevoelige persoonsgegevens worden gemaskeerd conform AVG. Trainingen voor ontwikkelaars en functioneel beheerders leggen uit welke query’s zij kunnen gebruiken, welke naamgevingsconventies gelden en hoe ze afwijkingen moeten escaleren. Dankzij deze organisatorische randvoorwaarden kan de maatregel breed worden omarmd en blijft de kwaliteit op niveau.

Een aanvullende vereiste is het borgen van gegevenslokalisatie en privacy-classificatie voordat logging wordt geactiveerd. Veel overheidsorganisaties werken met dataresidency-eisen die voorschrijven dat logbestanden uitsluitend in de West-Europese regio mogen worden bewaard en dat export naar derden alleen via goedgekeurde datadelingsovereenkomsten plaatsvindt. Daarom moeten architecten vooraf bepalen welke logvelden mogelijk staatsgeheim of bijzonder persoonsgegevens kunnen bevatten, hoe deze velden worden gehasht of gemaskeerd en welke bewaartermijnen gelden per classificatie. Door deze analyse onderdeel te maken van het projectstartdocument wordt voorkomen dat de organisatie later logs moet verwijderen of alsnog juridische uitzonderingen moet aanvragen.

Implementatie

De implementatie start met het vastleggen van een herhaalbare aanpak waarin alle App Services via hetzelfde patroon worden geconfigureerd. In een eerste stap wordt per abonnement bepaald welke werkruimte als primaire bestemming dient, welke resource tags moeten worden toegevoegd en welke deployment slots onder het change window vallen. Door deze beslissingen centraal te documenteren ontstaat een template die door alle lijnorganisaties kan worden gebruikt en die voldoet aan de kwaliteitscriteria van de Nederlandse Baseline voor Veilige Cloud.

Gebruik PowerShell-script appservice-http-logs-enabled.ps1 (functie Invoke-Implementation) – Automatiseert het inschakelen van AppServiceHTTPLogs en koppelt de gekozen Log Analytics-werkruimte.

Het aangeleverde PowerShell-script gebruikt de Az.Websites-module om alle App Services binnen een opgegeven resourcegroep of abonnement op te halen, controleert of er al diagnostic settings bestaan en voegt vervolgens de categorie AppServiceHTTPLogs toe met de gewenste retentie- en streamingopties. Het script logt elke stap naar een changelog zodat later kan worden aangetoond wanneer de configuratie is gezet. Beheerders voeren het script eerst uit in een sandbox waarbij slechts één applicatie wordt geraakt; pas na validatie wordt de scope vergroot naar alle productieapps.

Organisaties die liever via Azure Portal werken, volgen een duidelijk stappenplan: open de App Service, kies Monitoring, voeg een nieuwe diagnostische instelling toe, activeer AppServiceHTTPLogs, selecteer de juiste werkruimte en definieer een retentieperiode die past bij de bewaareisen. De portal dwingt directe validatie af doordat na inschakeling een testaanvraag kan worden verstuurd en de log binnen enkele seconden zichtbaar is in Log Analytics. Documenteer elke portalactie in het change ticket, zodat auditors kunnen aantonen dat ook handmatige wijzigingen gecontroleerd zijn uitgevoerd.

Voor grootschalige deployments is het aan te raden om dezelfde configuratie op te nemen in Infrastructure-as-Code artefacten zoals Bicep, Terraform of ARM-sjablonen. Daarmee wordt voorkomen dat nieuwe App Services zonder logging worden uitgerold. CI/CD-pipelines kunnen een validatiestap toevoegen die een policy- of template-test uitvoert voordat een release wordt goedgekeurd. Dit zorgt voor een structurele borging en maakt rollback eenvoudig wanneer onverwachte effecten optreden.

Na technische configuratie volgt een functionele validatie. Teams draaien KQL-query’s om te controleren of requests daadwerkelijk worden ingestroomd, vergelijken de aantallen met Application Insights metrics en zorgen dat PII-masking correct werkt. Performance-impact wordt gemonitord via de App Service metrics; omdat logging minimalistisch is, wordt meestal minder dan vijf milliseconden extra latency gemeten, maar het is belangrijk dit te documenteren om vragen van opdrachtgevers te beantwoorden. Eventuele afwijkingen worden opgenomen in een lesson-learned document.

Tot slot wordt de maatregel verankerd in de operationele workflow. Servicebeheerders registreren de configuratie in het CMDB-item van de applicatie, koppelen het aan het relevante BIO-controlebewijs en zorgen dat toekomstige releases de logging niet uitschakelen. Een periodieke review (bijvoorbeeld elk kwartaal) verifieert dat nieuw uitgerolde App Services automatisch aan het logging-beleid voldoen. Deze terugkerende controle voorkomt regressie en houdt het beveiligingsniveau consistent.

Communicatie richting stakeholders is een integraal onderdeel van de implementatiefase. Productowners en proceseigenaren moeten weten welke extra inzichten beschikbaar komen, hoe zij toegang kunnen krijgen tot rapportages en welke responstijden worden gehanteerd wanneer zij een logaanvraag indienen. Door tijdens de implementatie een korte trainingssessie te organiseren waarin het gebruik van Log Analytics workbooks wordt getoond en waarin afspraken worden gemaakt over dataminimalisatie, groeit het vertrouwen in de oplossing en wordt het draagvlak voor toekomstig onderhoud vergroot.

Compliance en Auditing

App Service HTTP logging levert concreet bewijs binnen meerdere compliancekaders die relevant zijn voor Nederlandse overheidsorganisaties. De maatregel sluit rechtstreeks aan op BIO 12.04 waarin wordt geëist dat alle toegang tot informatievoorzieningen wordt vastgelegd en dat loggegevens zeven jaar beschikbaar blijven. Door elke webaanvraag met bronadres, methode, pad en resultaat vast te leggen, kan een auditor reconstrueren wie wanneer welke gegevens probeerde te benaderen.

Binnen het CIS Microsoft Azure Foundations Benchmark beschrijft controle 9.10 dat App Service logging verplicht is voor organisaties die applicaties in Azure hosten. Deze repository borgt dat de aanbevolen categorie AppServiceHTTPLogs is geactiveerd, dat logs naar een centraal beheerde workspace worden gestuurd en dat retentie eenvoudig kan worden aangetoond. Tijdens een CIS-audit kan het change ticket samen met de Log Analytics configuratie als bewijs dienen.

Ook de AVG is direct van toepassing omdat IP-adressen en gebruikersagenten als persoonsgegevens worden beschouwd. Artikel 32 vereist passende technische maatregelen om incidenten te detecteren en achteraf te onderzoeken. Zonder HTTP logs kan een organisatie niet aantonen dat er inspanningen zijn geleverd om datalekken te ontdekken. Door logging te combineren met bewaarbeleid en toegangscontrole op de workspace, voldoet men aan het principe van privacy-by-design: loggen wat nodig is, beschermen wat wordt opgeslagen en enkel geautoriseerde teams laten zoeken.

De NIS2-richtlijn en het aanstaande Nederlandse wetsvoorstel Wet beveiliging netwerk- en informatiesystemen 2 vragen expliciet om monitoring van essentiële diensten. HTTP logging is een van de basisbronnen waarmee incidentrespons binnen de wettelijke meldtermijn kan worden uitgevoerd. Door in procedures op te nemen dat elke melding richting Agentschap Telecom of NCSC wordt onderbouwd met App Service logextracten, kan de organisatie aantonen dat zij aan de zorgplicht voldoet.

Tot slot ondersteunt deze maatregel ISO 27001 controles A.16 (incidentmanagement) en A.12.4 (logging en monitoring). Het volwassenheidsmodel van de Nederlandse Baseline voor Veilige Cloud vraagt om aantoonbare bewijslast, en de hier beschreven configuratie voorziet daarin. Zorg ervoor dat het auditdossier de volgende artefacten bevat: export van de diagnostische instelling, beschrijving van de bewaartermijn, voorbeeldquery’s en een rapportage van de kwartaalcontrole. Daarmee kan elke interne of externe auditor de effectiviteit van de logging binnen enkele minuten vaststellen.

Sectorspecifieke richtlijnen, zoals de Baseline Informatiebeveiliging Waterschappen en de Baseline Informatiebeveiliging Gemeenten, nemen de BIO-eisen over maar voegen vaak aanvullende verplichtingen toe rondom ketenafspraken en logging van publieke dienstverlening. Door HTTP logging consequent op te nemen in de service level agreements met leveranciers en shared service centers, wordt geborgd dat externe partijen dezelfde standaarden aanhouden en dat uitbestede platformen dezelfde audittrail kunnen opleveren als interne voorzieningen.

Bij certificeringstrajecten wordt regelmatig gevraagd naar bewijs van periodieke review. Daarom is het verstandig om in de jaarplanning van de interne auditdienst een vaste controle op te nemen waarbij steekproefsgewijs App Services worden bekeken. De auditrapportage koppelt bevindingen direct aan risicoregisters en verbeterplannen, zodat bestuurders inzicht krijgen in de resterende risico’s en de voortgang van de maatregelen. Deze governancecyclus toont aan dat naleving geen eenmalige inspanning is maar een doorlopend proces.

Voor organisaties die samenwerken binnen internationale programma’s, zoals grensoverschrijdende uitwisseling van gegevens tussen Benelux-landen, is het noodzakelijk om aan te tonen dat logging niet alleen aanwezig is maar ook voldoet aan afspraken over gegevensdeling. Door in de logging-architectuur expliciet vast te leggen welke datasets de landsgrenzen mogen verlaten, hoe gegevens worden geanonimiseerd voordat zij met partners worden gedeeld en hoe toegang wordt gecontroleerd via Azure AD PIM, wordt voldaan aan aanvullende contractuele verplichtingen. Dit voorkomt discussies tijdens audits van externe toezichthouders of Europese instellingen.

Monitoring

Gebruik PowerShell-script appservice-http-logs-enabled.ps1 (functie Invoke-Monitoring) – Controleert of AppServiceHTTPLogs is ingeschakeld en vergelijkt de configuratie met de referentiestand.

Monitoring begint met het dagelijks valideren of de ingestelde diagnostische regels nog aanwezig zijn. Het aangeleverde script bevat een monitoringfunctie die per App Service controleert of AppServiceHTTPLogs actief is, welke Log Analytics-werkruimte is gekoppeld en of retentie-instellingen overeenkomen met het standaardbeleid. De resultaten worden naar een CSV of Log Analytics tabel geschreven zodat afwijkingen direct zichtbaar worden in dashboards.

Naast configuratievalidatie is inhoudelijke monitoring noodzakelijk. KQL-query’s filteren op responscodes, vergelijken pieken per IP-adres en zoeken naar anomalieën in user agents of query strings. Deze query’s worden vertaald naar Azure Monitor alerts die het SOC waarschuwen bij verdacht gedrag, zoals honderden 404’s in korte tijd of plotseling veel POST-verzoeken naar een beheerpad. Door alertregels te koppelen aan een SOAR-playbook ontstaat geautomatiseerde triage waarbij direct aanvullende context uit Defender for Cloud wordt opgehaald.

Dezelfde logs worden gebruikt om servicekwaliteit te meten. Operationele dashboards tonen de gemiddelde responstijd per endpoint, geografische verdeling van verkeer en trends in TLS-versies. Wanneer een release performanceproblemen veroorzaakt, kan het beheerteam binnen minuten aantonen welk onderdeel verantwoordelijk is. Deze inzichten worden gedeeld in de wekelijkse operationele meeting en opgeslagen in het kwaliteitsdossier.

Auditors eisen dat ook toegang tot de logs zelf wordt gemonitord. Daarom wordt Log Analytics role-based access logging gecombineerd met Microsoft Purview audit logging, zodat duidelijk is welke analist welke query heeft uitgevoerd. Eventuele exports bevatten pseudonimisering en worden geregistreerd in een datalekregister wanneer IP-adressen buiten de primaire verwerking worden gedeeld. Deze governance waarborgt dat monitoring zowel effectief als privacyvriendelijk blijft.

Tot slot wordt monitoring onderdeel van de reguliere continuïteitsprocessen. Elke maand draait een compliance-rapport waarin staat hoeveel App Services gecontroleerd zijn, hoeveel afwijkingen zijn gevonden en welke acties zijn genomen. Dit rapport wordt besproken in het security governance board en vormt input voor het risicoregister. Op deze manier blijft het onderwerp top-of-mind bij management en kunnen middelen worden vrijgemaakt om achterstanden snel weg te werken.

Om de betrouwbaarheid verder te vergroten wordt een synthetische workload ingezet die periodiek testaanvragen naar elke App Service stuurt. De resultaten worden vergeleken met de daadwerkelijk geregistreerde logs; wanneer een testrequest niet verschijnt, is dat een duidelijke indicatie dat de loggingketen is onderbroken. Deze techniek helpt om niet alleen configuratiefouten maar ook opslag- of netwerkproblemen vroegtijdig op te merken.

Daarnaast wordt monitoring gekoppeld aan business metrics. Door HTTP logs te correleren met serviceafspraken (zoals beschikbaarheid van een burgerportaal of responstijden van een vergunningensysteem) ontstaat een holistische rapportage die direct bruikbaar is voor directies. Wanneer een KPI wordt overschreden, kan het team dankzij de rijke logging aantonen of de oorzaak in gebruikspatronen, infrastructuur of applicaties ligt. Dit versnelt besluitvorming en legitimeert investeringen in extra capaciteit of beveiligingsmaatregelen.

Als laatste stap wordt monitoring geïntegreerd in het capaciteits- en kostenbeheer. Door trends in requestvolumes en datagroei te analyseren kan het FinOps-team tijdig aanpassingen doen aan Log Analytics commitment tiers en opslagaccounts. Deze gegevens voeden begrotingscycli, zorgen dat er geen onverwachte kostenposten ontstaan en maken het mogelijk om besparingen te realiseren door oude logbestanden automatisch naar archiefniveau te verplaatsen zonder de wettelijke bewaartermijnen te schenden.

Remediatie

Gebruik PowerShell-script appservice-http-logs-enabled.ps1 (functie Invoke-Remediation) – Herstelt de diagnostische instelling automatisch naar de referentieconfiguratie.

Wanneer monitoring uitwijst dat een App Service geen HTTP logging meer heeft, moet binnen hetzelfde change window een herstelactie plaatsvinden. Het remediatiescript leest de referentieconfiguratie uit een JSON-profiel, maakt indien nodig een nieuwe diagnostische instelling aan en koppelt direct de juiste Log Analytics-werkruimte. Elke run wordt voorzien van een ticketnummer zodat de volledige keten traceerbaar blijft.

Automatische remediatie wordt idealiter geïntegreerd in Azure Policy. Een deployIfNotExists-beleid controleert bij elke nieuwe App Service of de logging ontbreekt en triggert het script. Hierdoor hoeven beheerders niet te wachten op maandelijkse controles; afwijkingen worden binnen enkele minuten opgelost. Policy-compliance rapportages tonen hoeveel resources hersteld zijn en bieden input voor trendanalyses.

In uitzonderlijke situaties kan logging tijdelijk worden uitgeschakeld, bijvoorbeeld tijdens een performance-onderzoek. In dat geval moet het change ticket expliciet vermelden wanneer de logging weer wordt aangezet, welke compenserende maatregelen (bijvoorbeeld WAF-logging) actief zijn en hoe gemiste loggebeurtenissen worden gedocumenteerd. Deze afspraken voorkomen dat tijdelijke uitzonderingen permanent worden.

Na elk herstel wordt een post-remediation check uitgevoerd waarbij zowel het scriptresultaat als een handmatige KQL-query bevestigt dat nieuwe requests zichtbaar zijn. De bevindingen worden gedeeld met applicatie-eigenaren zodat zij weten dat er een korte periode zonder logging was en welke risico’s dat gaf. Eventuele lessons learned worden toegevoegd aan het operationele handboek.

Structurele oorzaken zoals foutieve IaC-sjablonen, onvolledige documentatie of onvoldoende rechten worden opgenomen in het probleembeheerrapport. Het CISO-office beoordeelt elk kwartaal of aanvullende maatregelen nodig zijn, zoals extra policies, strengere RBAC-instellingen of verplichte training voor DevOps-teams. Door remediatiegegevens zo te analyseren ontstaat continue verbetering in lijn met de Nederlandse Baseline voor Veilige Cloud.

Voor kritieke diensten is het zinvol om remediatieprocessen te oefenen tijdens table-top scenario’s en technische dry-runs. Daarbij wordt nagebootst dat een App Service zonder logging is uitgerold en moeten teams aantonen hoe snel zij het script starten, welke validatiestappen zij uitvoeren en hoe zij stakeholders informeren. De resultaten van deze oefeningen worden vastgelegd in het BCM-dossier en leveren bewijs dat de organisatie voorbereid is op logonderbrekingen.

Ten slotte wordt remediatie verankerd in contracten met leveranciers en softwarefabrieken. SLA’s bevatten een clausule die stelt dat elke wijziging aan App Service configuraties automatisch een controle op diagnostische instellingen moet uitvoeren en dat afwijkingen binnen 24 uur moeten zijn opgelost. Door deze verplichting contractueel vast te leggen, kan de opdrachtgever afdwingen dat ook externe partijen conform de Nederlandse Baseline voor Veilige Cloud handelen en dat de audittrail sluitend blijft.

Wanneer remediatie meerdere keren op dezelfde applicatie moet worden uitgevoerd, volgt een root cause analyse waarin wordt onderzocht waarom de configuratie telkens verdwijnt. Mogelijke oorzaken zijn pipelines die oude ARM-sjablonen gebruiken, third-party beheerportalen die slechts gedeeltelijke instellingen toepassen of menselijke fouten tijdens noodreleases. De analyse resulteert in concrete acties, zoals het blokkeren van verouderde pipelines via Azure DevOps approvals of het toevoegen van extra validatiescripts in de release-definitie.

Tot slot wordt elke remediatie geëvalueerd op effectiviteit via key risk indicators, bijvoorbeeld het aantal dagen dat een applicatie zonder logging heeft gedraaid of het aantal openstaande uitzonderingen. Deze indicatoren worden opgenomen in het kwartaalrapport aan het security governance board en vormen input voor strategische beslissingen. Wanneer de indicatoren verslechteren, kan het bestuur besluiten om aanvullende middelen toe te wijzen, zoals een dedicated logging squad of extra tooling, zodat de maatregel duurzaam geborgd blijft.

Compliance & Frameworks

• CIS M365: Control 9.10 (L2) - App Service logging
• BIO: 12.04 - Web logging

Automation

Gebruik het onderstaande PowerShell script om deze security control te monitoren en te implementeren. Het script bevat functies voor zowel monitoring (-Monitoring) als remediation (-Remediation).

Risico zonder implementatie

Management Samenvatting

HTTP-aanvraaglogging levert het primaire bewijs voor incidentrespons, naleving en prestatieanalyse. Activeer de diagnostische instelling, valideer dat logs aankomen in Log Analytics, stel alerts in voor verdacht verkeer en documenteer de configuratie in het change- en auditdossier.

• Implementatietijd: 1 uur
• FTE required: 0.03 FTE