Overzicht veelgestelde vragen over ISD Informatievoorziening Sociaal Domein

Hieronder treft u de categorieen aan met vragen en antwoorden binnen het betreffende dossier. U kunt deze openklappen en lezen door op een categorie/vraag te klikken.

Het Zorginstituut Nederland bundelt op haar website iStandaarden de veelgestelde vragen over verschillende onderwerpen en modules.

U vindt daar antwoorden over onder meer: iWmo, de Validatiemodule, Conversiemodule, Wachtlijstinformatie, Verwijsindex Productcodes en de iStandaarden overgang 2015-2016.

De gemeente doet als verantwoordelijke een risicoinschatting / risicoanalyse. Daaruit volgen dan beveiligingsmaatregelen die nodig zijn bij de bewerker die de gemeente als verantwoordelijke eist.

De beveiligingseisen horen terug te komen in de volgende documenten van de gemeente:

De beveiligingseisen dienen periodiek gecontroleerd te worden door de gemeente, of de leverancier overlegt een TPM.

Ja, bij het gebruik van persoonsgegevens blijft de gemeente verantwoordelijk, zie Wet Bescherming Persoonsgegevens, artikel 14. 

Hergebruik buiten het doel (doelbinding) waarvoor verzameld is niet toegestaan (zie paragraaf 2.1 van de Wbp). Doorlevering is in principe niet toegestaan tenzij daarvoor een bepaalde wettelijke basis is.

Nee. Iedere gemeente moet zelf verantwoorden hoe het staat ten opzichte van de Baseline Informatiebeveiliging Nederlandse Gemeenten (BIG). Elke gemeente regelt in het convenant met een samenwerkingsverband wat de rechten, de plichten en de verantwoording zijn naar de gemeente toe. Dit convenant kan ook gezien worden als een vorm van een Bewerkersovereenkomst.

Dit kan onder andere door:

  • Periodiek een TPM of eigen audit
  • Inzage krijgen in, of het verstrekken van logginggegevens

Zie ook:

Er is gekozen voor een optimale aansluiting bij de wereld van geaccepteerde standaarden, ISO 27001:2005 en ISO 27002:2007 en de daarvan afgeleide overheidsstandaarden zoals de VIR/BIR.

Als een organisatieonderdeel of een toeleverancier haar zaken op orde heeft volgens ISO 27001:2005, rekening houdend met de implementatiemaatregelen uit ISO 27002:2007, dan hoeft die organisatie slechts te controleren op de aanvullende bepalingen voor bijvoorbeeld aansluitvoorwaarden voor een specifiek register.

De volgende normen bestaan binnen de rijksoverheid. Ze zijn niet van toepassing op gemeenten maar de Strategische en Tactische Baseline BIG) zijn nauw verwant aan deze normen:

  • Het Besluit Voorschrift Informatiebeveiliging Rijksdienst (VIR)
  • Het Besluit Voorschrift Informatiebeveiliging - Bijzondere Informatie (VIR-bi)
  • De Baseline Informatiebeveiliging Rijk (BIR), bestaande uit BIR-TNK (tactisch normenkader) en BIR-OP (Operationele baseline)
  • De Interprovinciale Baseline Informatiebeveiliging

Het VIR heeft ook een relatie met het Algemeen Rijksambtenarenreglement (ARAR). Het ARAR is niet op gemeenten van toepassing, daarvoor heeft men de CAR-UWO en de Ambtenarenwet. 

Ja. De Taskforce Bestuur en Informatieveiligheid Dienstverlening (BID) leidt het project Eenduidige Normatiek Single Information Audit (ENSIA). Dit project moet antwoord geven op de vraag hoe horizontaal (intern) en verticaal (extern) verantwoord moet worden. Verticale verantwoording is in de lijn (naar de wetgevers toe) en horizontale verantwoording is naar de Raad en naar de inwoners.

De voorlopige uitkomst van ENSIA is dat er een selfassessment komt waarvan de uitkomst getekend moet worden door de gemeentesecretaris (In Control Statement). Daarna kan het geheel door de interne of huisauditor beoordeeld worden (proces audit) en wordt de rapportage meegenomen in de SISA verantwoordingbijlage en daarnaast horizontaal aan de Raad en de inwoners met het jaarverslag.

Let wel: het project is nog niet afgelopen en dus is bovenstaande onder voorbehoud.

Ja, voorlopig wel. De wijzigingen onder invloed van het project Eenduidige Normatiek Single Information Audit (ENSIA) hebben tijd nodig om politiek te landen bij de verschillende wetgevers en inspecties. Daarnaast is het project ENSIA nog niet afgelopen is, dus er zijn nog geen conclusies getrokken en er zijn nog geen adviezen naar de verschillende wetgevers gegaan. 

Dat neemt niet weg dat de horizontale en verticale verantwoording niet nu al niet kan worden ingericht. Als een gemeente de Baseline Informatiebeveiliging Nederlandse Gemeenten (BIG) implementeert en binnen het gemeentelijke informatiebeveiligingsbeleid en het informatiebeveiligingsplan, de verschillende normen (SUWI, BPR, BAG, reisdocumenten, DigiD) nadrukkelijk een plaats geeft, dan kan de auditlast afnemen als gevolg van het sneller kunnen doorlopen van de verschillende audits. Het kernpunt hierbij is dossiervorming en bewijsvoering. 

Voor de gemeente zijn de Baseline Informatiebeveiliging Nederlandse Gemeenten (BIG) operationele producten van de Informatie Beveiligingsdienst (IBD) het normenkader voor informatiebeveiliging.

Wat de eisen zijn hangt helemaal af van het soort softwarepakket, het doel en de functie en waar het softwarepakket gebruikt wordt. Aandachtspunt is dat vaak pakketten worden aangeschaft waarbij 'one size fits all' geldt voor de leverancier. Terwijl het gebruik, de registratie van gegevens en de soort gegevens per gemeente kunnen verschillen, waardoor er bijvoorbeeld beveiligingseisen ontstaan waar de leverancier niet op gerekend heeft.

Een voorbeeld daarvan is de mogelijkheid om gegevens af te schermen voor specifieke gebruikers of groepen, maar ook de mate waarin logging wordt ondersteund. Denk ook aan integratie met andere systemen. In dit voorbeeld bestaat de kans dat de gemeente met meer eisen zal opdraaien voor de kosten, of erger, een eigen specifieke versie van een product krijgt.

Het antwoord op veel algemene beveiligingsvragen vindt u in:

De burger heeft het recht om zijn persoonsgegevens in te zien en te kunnen wijzigen. Dit kan ook gewoon door een print te maken van de informatie die aanwezig is.

Wanneer er gewerkt wordt met een plan van aanpak rondom één gezin en er dus persoonsgegevens van meerdere personen in één document staan, moet men bij het beschikbaar stellen van de gegevens aan de klant rekening houden met de privacy van de andere gezinsleden. Dit wil zeggen dat de informatie over partners en kinderen ouder dan 16 jaar niet zonder toestemming van die personen verstrekt mag worden.

De klant heeft het recht om te weten wie er toegang heeft tot zijn of haar gegevens en met wie er persoonsgegevens gedeeld worden. Maak de afweging ten aanzien van noodzaak, proportionaliteit en subsidiariteit in een triagebesluit expliciet over welke informatie er met wie gedeeld wordt en waarom. Als deze afweging is vastgelegd, kunt u als gemeente aan de burger uitleggen wat er met zijn/haar gegevens gebeurt en waarom.

Logging in de applicatie en op databaseniveau van alle vormen van mutaties, rechtentoewijzingen. Voor de controle van logging beveelt Baseline Informatiebeveiliging Nederlandse Gemeenten (BIG) aan iemand de taak toe te wijzen deze logging te controleren. Bij voorkeur iemand die niet inhoudelijk met de applicatie of het systeem werkt.

Uitzonderingen en regels dienen vooraf gedefinieerd te worden en daarover dient periodiek gerapporteerd te worden.

Volledige vraag
Voor het bevragen van gegevensbronnen moet ik mij houden aan de doelbinding (wettelijk verankerd). Maar hoe zit het nu met het beschikbaar stellen van informatie die ik als gemeente al heb ingewonnen, voor andere taken (hergebruik)?

Antwoord
Ook voor het beschikbaar stellen van informatie die u als gemeente al heeft, is men gebonden aan de Wet beschermings persoonsgegevens. In de kabinetsvisie over privacy staat hier een en ander over geschreven. De visie stelt dat de hulpvraag van de burger leidend is. Op basis van de vraag en de informatie die de burger geeft, kan het klantbeeld worden bepaald. Het is niet de bedoeling dat er voorafgaand aan een hulpvraag al een integraal klantbeeld wordt opgesteld op basis van beschikbare informatie.

De noodzakelijke gegevensverwerking is sterk situationeel. De professionele inschatting telt. Voor een simpele en enkelvoudige vraag is het niet noodzakelijk om gegevens op te vragen (uit gegevens die binnen de gemeente beschikbaar zijn of via externe partijen) maar wanneer er sprake is van een multiprobleemsituatie kan het wel noodzakelijk zijn om meer informatie te verzamelen.

Door triagemomenten in het proces in te richten kan de professional op verschillende momenten een afweging maken over de noodzakelijke gegevensverwerking (noodzaak, proportionaliteit en subsidiariteit). In de Factsheet Triage staat beschreven waarom triage belangrijk is en welke triagemomenten er onderscheiden worden in het sociaal domein.

Vanuit beveiligingsoogpunt is het e-mailen van ongestructureerde persoonsgerelateerde informatie af te raden, iedereen kan in principe de inhoud van de mail lezen als geen beveiligingsmaatregelen worden getroffen.Maatregelen kunnen zijn het versleutelen (encryptie) van de inhoud op basis van bijvoorbeeld PKI-sleutels.

Voor het uitwisselen van ongestructureerde persoonsgerelateerde informatie kan bijvoorbeeld wel gebruik gemaakt worden van mijnoverheid.nl om te communiceren met burgers en via digikoppeling met bedrijven.

Welke authenticatiemiddelen u in kunt zetten hangt af van het soort gegevens en de verbindingsweg. Bij algemene persoonsgegevens is minimaal gebruikersnaam en wachtwoord nodig en een beveiligde verbinding (https). Bij medisch geheim is minimaal 2 factor authenticatie door middel van een token nodig.

Meer informatie

Voor het veilig laten ontwikkelen kan gebruik worden gemaakt van de methode Grip op secure sofware development (SSD). Deze methode beschrijft hoe de gemeente (opdrachtgever) grip krijgt op het ontwikkelen van goed beveiligde software.

De beveiligingseisen die de gemeente (opdrachtgever) kan hanteren als eisen aan de op te leveren software, zijn beschreven in het document Grip op SSD: SIVA Beveiligingseisen. Beide documenten zijn ontwikkeld en gepubliceerd door Centrum voor Informatiebeveiliging en Privacybescherming (CIP).

In de kabinetsvisie over privacy 'Zorgvuldig en bewust' staat dat de hulpvraag van de burger leidend is. Op basis van de vraag en de informatie die de burger geeft, kan de professional zich een klantbeeld vormen. Voorafgaand aan de hulpvraag mag en hoeft nog geen integraal klantbeeld opgesteld te worden op basis van de al beschikbare informatie. De noodzakelijke gegevensverwerking is sterk situationeel. De professionele inschatting telt.

Voor een simpele en enkelvoudige vraag is het niet noodzakelijk om gegevens op te vragen, bijvoorbeeld uit gegevens die binnen de gemeente beschikbaar zijn of via externe partijen. Wanneer er sprake is van een multiprobleemsituatie kan het wel noodzakelijk zijn om meer informatie te verzamelen.

Door triagemomenten in het proces in te richten kan de professional op verschillende momenten een afweging maken over de noodzakelijke gegevensverwerking (noodzaak, proportionaliteit en subsidiariteit). In de Factsheet Triage staat het belang van triage en en welke triagemomenten er kunnen zijn in het sociaal domein.

Het vertalen van reeds ingekochte, gemeentespecifieke productcodes naar de standaard productcodes is vrijwel altijd mogelijk.

Gemeenten die tot vertaling over willen gaan kunnen zelf een vertaling maken en deze desgewenst voorleggen aan experts van de VNG.

Nee, tenzij gemeente en aanbieder dat gezamenlijk expliciet afspreken. De lijst is allereerst bedoeld om bij nieuwe contracten en het berichtenverkeer daarover te gebruiken. Bestaande productcategorieën en productcodes kunnen ook in 2016 nog worden gebruikt in het iWmo- en iJw-berichtenverkeer.

Factureren/declareren van producten
Voor het declareren/factureren van zorg die geleverd is binnen de Specialistische GGZ (DBC’s) dan wel Basis GGZ (producten Basis-GGZ) kan gebruikt gemaakt worden van het JW321/JW322-bericht. In het JW321/JW322- bericht kunnen de standaard productcodes van de NZa worden gehanteerd. Hierin kan dus geen gebruik gemaakt worden van de codes uit de standaard productcodetabel. 

Factureren/declareren van onderhanden werk
Gemeenten en aanbieders die hebben afgesproken om tussentijds onderhanden werk te declareren kunnen gebruik maken van het JW303/JW304-bericht. Hiervoor kunnen ook de productcategorieën Generalistische Basis GGZ (51) en Specialistische GGZ (52) worden gebruikt. Deze tussentijdse facturatie wordt onder andere toegepast bij landelijke aanbieders die geen voorschot ontvangen en op die manier kunnen zorgen voor voldoende liquiditeit.

Het online vragenuur over productcodes van 24 augustus 2015, geeft onder meer antwoord op vragen over:

  • De inhoud van de productcodelijsten: bijv. hoe zijn de lijsten opgebouwd en hoe moet ik de begrippen die in de lijsten gehanteerd worden interpreteren?
  • Het gebruik en beheer van de productcodelijsten: bijv. hoe vertaal ik mijn producten naar de productcodes die in de lijsten gehanteerd worden? Hoe ga ik om met bestaande productcodes en worden uitzonderingen op de standaardlijsten toegestaan?

Presentatie toelichting productcodetabellen iWmo en iJw
(VNG/KING, online vragenuur 24 augustus 2015, pdf)

De productcategorieën in deze lijst zijn niet één op één gekoppeld aan de acht categorieën beleidsinformatie van CBS. De beleidsinformatie van CBS moet door aanbieders worden aangeleverd, terwijl deze nieuwe productcategorieën gebruikt worden voor het berichtenverkeer tussen gemeenten en aanbieders en gemeenten en de SVB. 

Gemeenten zijn niet verplicht om met de standaard productcodetabel te werken. Omwille van het gezamenlijk belang van het terugdringen van administratieve lasten wordt wel met klem aangeraden om - waar mogelijk - tot het gebruik van de standaard productcodes over te gaan.

In de 2.0-versie van de standaardberichten iWmo en iJw is de productcategorie een verplicht veld en de productcode een optioneel veld. 

In de productcodetabel zijn twee productcategorieën opgenomen. Generalistische Basis GGZ (51) en Specialistische GGZ (52). Deze productcategorieën kunnen worden gebruikt voor het toewijzen van zorg binnen de Generalistische Basis GGZ, respectievelijk Specialistische GGZ. 

Voor de Jeugdwet zijn de productcodes voor landelijk ingekochte producten opgenomen in de iJW productcodetabel 2.0. Deze zijn één-op-één overgenomen uit de iJW productcodetabel 1.0; er zijn dus geen codes gewijzigd of toegevoegd. Het toevoegen heeft als voordeel dat gemeenten nu voor zowel lokaal ingekochte als landelijke ingekochte producten gebruik kunnen maken van de iJW productcodetabel 2.0.

De landelijke ingekochte producten binnen de Wmo (ondersteuning zintuigelijk gehandicapten) zijn tevens opgenomen in de iWmo productcodetabel 2.0. Hier zijn wel nieuwe producten toegevoegd. In tegenstelling tot de productcodes uit de iWmo productcodetabel 1.0 maken de nieuwe codes voor ZG maken onderscheid tussen de doelgroepen doofblinden visueel gehandicapten en vroegdoven. De codes zijn te herkennen aan de derde positie die altijd een L is.

De vertaling dient slechts als leidraad. Mocht er een reden zijn waarom de aanbieder wil afwijken van de voorgestelde vertaling (bijvoorbeeld omdat de instelling de zorg/ondersteuning in een specifieke/setting of vorm levert) dan kan dat. Het informatieprotocol Beleidsinformatie Jeugd is hierin leidend.

In 2016 mogen de oude productcategorieën door gemeenten ook nog worden gehanteerd. 

Voor alle berichten waarin productcategorie of productcode in voorkomen:

  • Toewijzing (301)
  • Declaratie/Factuur (303)
  • Start Zorg en Ondersteuning (305)
  • Stop Zorg en Ondersteuning (307)
  • Verzoek om Toewijzing (315)

Voor de JW321 geldt de productcodetabel niet, daar is een lijst voor vanuit de Nza waarin alle GGZ-producten staan uit de bekostiging van de Zorgverzekeringswet, die de eerste drie jaar van de transitie door gemeenten is overgenomen. Het gaat zowel om producten uit de Generalistische Basis-ggz als om DBC’s uit de Gespecialiseerde GGZ. 

Per 1 januari 2016 zijn gemeenten verantwoordelijk voor de nieuwe instroom van cliënten met jeugd-GGZ door kinderartsen. Zij werden niet ingekocht volgens de DBC-systematiek, en hebben daarom in deze lijst wel een plaats gekregen.

In tegenstelling tot de productcodes uit de iWmo productcodetabel 1.0 maken de nieuwe codes voor ZG maken onderscheid tussen de doelgroepen doofblinden, visueel gehandicapten en vroegdoven. Dit onderscheid is gemaakt, omdat aanbieders bij wie ondersteuning voor meerdere doelgroepen is ingekocht aangaven de productcodes niet goed te kunnen verwerken in hun systemen.

Met de codes uit 2015 kon dit verschil niet gemaakt worden, waardoor onduidelijkheid met declareren optrad.

De laatste twee kolommen van de productcodetabel iJW 2.0 dienen als handvat voor aanbieders die de vertaling maken van de productcodes naar de dimensies hulpvorm zoals die in de Beleidsinformatie Jeugd worden gehanteerd.

Deze productcategorieën blijven ongewijzigd. De productcategorieën Wmo worden niet alleen gebruikt in het iWmo-berichtenverkeer, maar ook in aanleveringen aan het CAK, de SVB en het CBS. De bestaande productcategorieën zijn gebruikt als ordening voor de nieuwe standaardproductcodetabel voor Wmo.

De Verwijsindex productcodes Wmo en Jeugd, een centrale voorziening voor gemeente-specifieke lijsten, zal in 2016 nog wel raadpleegbaar blijven, maar mutaties zijn niet meer mogelijk.

Na de publicatie van de eerste productcodetabel 2.0 in juli 2015 zijn diverse bijeenkomsten geweest over het gebruik van productcodes en zijn bij de VNG diverse aanvullingsverzoeken binnengekomen. Deze verzoeken zijn verwerkt en de nieuwe lijst is hier het resultaat van. Een volledig overzicht van de wijzigingen in de oktober 2015 lijst is beschikbaar in de release notes.

Daarnaast bevat de productcodetabel nu de alternatieve productcodelijst van Jeugdzorg Nederland. De codes zijn tot stand gekomen op basis van een consultatie bij jeugdzorgaanbieders, gecertificeerde instellingen en gemeenten. De codes zijn te herkennen doordat de derde positie van de code altijd een B is.

Voor zowel gemeenten als zorgaanbieders heeft het werken met de standaardlijsten veel voordelen.

De administratieve afdelingen van zorgaanbieders die werken voor meerdere gemeenten moeten op dit moment extra mankracht inzetten voor het administratief verwerken van de veelvoud aan productcodes. Daarbij maken zij veelal gebruik van een eigen vertaaltabel of systematiek. Dat levert onnodige extra mankracht op de administratie en bij ICT op.

Ook bij gemeenten leidt de grote hoeveelheid aan productcodes op dit moment tot veel verwarring in de uitvoering. Er wordt veel extra onnodige tijd gestoken in het ontcijferen van productcodes. Dit geldt onder andere bij het toewijzen van zorg. Daarnaast bieden de standaardlijsten het voordeel dat gemeenten zelf geen lijsten hoeven te beheren. Door gebruik te maken van de standaardlijst kunnen de administratieve processen bij gemeenten en zorgaanbieders vereenvoudigd worden.

Nu een standaardproductcodetabel beschikbaar is gekomen, wordt de ondersteuning voor gemeentespecifieke lijsten in 2016 teruggebracht. Het is nog steeds mogelijk om met afwijkende codes te werken, maar gemeenten zijn zelf verantwoordelijk om daarover afspraken te maken met zorgaanbieders en de codetabellen beschikbaar te stellen.

De Verwijsindex productcodes Wmo en Jeugd, een centrale voorziening voor gemeente-specifieke lijsten, zal in 2016 nog wel raadpleegbaar blijven, maar mutaties zijn niet meer mogelijk.

In het iWmo- en iJw-berichtenverkeer worden vanaf versie 2.0 drie uitvoeringsvarianten onderscheiden: inspannings-, output- en taakgericht.

De standaardproductcodetabel is bruikbaar in de inspannings- en outputgerichte uitvoeringsvariant, waar de gemeente op cliëntniveau gegevens uitwisselt met de aanbieder van zorg of ondersteuning.

Jaarlijks is een TPM of eigen audit nodig. Maak vooraf afspraken met betrekking tot het zogenoemde ‘right to audit’, zodat de gemeente of een auditor in opdracht van de gemeente in staat gesteld wordt om bepaalde processen en de gegevensverwerking te kunnen controleren en beoordelen.

De beveiligingseisen zijn afhankelijk van de soort gegevens, applicatie en dienst die u als gemeente in de SaaS-oplossing (Software as a Service) wilt gaan gebruiken. Een voorbeeld is te vinden in het operationele Baseline Informatiebeveiliging Nederlandse Gemeenten (BIG)-product Bewerkersovereenkomst van de Informatie Beveiligingsdienst (IBD). Hierin zijn ook de moogelijke maatregelen opgenomen.

Als gemeente bent u zelf verantwoordelijk voor het maken van een inschatting of de genomen maatregelen afdoende dekkend zijn voor de risico's die gelopen worden.

Toegang voor burgers kan op dezelfde manier geregeld worden als bij een eigen oplossing vanuit de gemeente. Er moet een portaal komen waar de burger met DigiD kan inloggen, waar de informatie dan getoond wordt als er een klantcase is. Bij SaaS moet er dus een portaal zijn die aparte informatie ontsluit. Een mogelijke oplossing is de digitale berichtenbox van mijnoverheid.nl.

Bij een SaaS-oplossing gaat de gemeente niet meer over functioneel en technisch beheer. Functioneel beheer zoals het (functioneel) parametriseren van de applicatie en gebruikersbeheer kan nog wel door de gemeente worden uitgevoerd.

Het identificatie- en authenticatieproces is het vaststellen wie iemand is. Het autorisatieproces is het bepalen en vastleggen welke toegang deze persoon heeft binnen een bepaald informatiesysteem. De autorisatie kan met speciale tooling worden beheerd (IAM-tools) en indien een koppeling bestaat met een applicatie kunnen de gegevens worden uitgewisseld.

Er zijn niet veel gemeenten die dit op deze manier doen. In de praktijk staan eindgebruikers in een adresgids (LDAP of active directory). Los daarvan wordt vaak per applicatie bijgehouden welke eindgebruikers waar toegang hebben in de applicatie zelf. Dit is vaak een handmatig proces op basis van bijvoorbeeld een getekend autorisatieformulier van een manager. Deze autorisaties worden dan door een functioneel beheerder middels een aparte beheerpagina in een webapplicatie verwerkt.

Vanaf welke locaties toegang tot de SaaS-oplossing moet worden toegestaan is van een aantal zaken afhankelijk, zoals:

  • de gegevens (inhoud)
  • de plaats (geografisch)
  • wetgeving (soms is het niet toegestaan met bepaalde gegevens te werken buiten de gemeentelocatie)

Meer informatie

Volledige vraag
Hoe garandeer ik de continuïteit van de SaaS-applicatie en de beschikbaarheid van de data in geval van een faillissement van de SaaS-leverancier, of wanneer de leverancier anderszins in gebreke blijft?

Antwoord
Zowel de gemeente (cloudafnemer) als hun leveranciers dienen hun verantwoordelijkheid te nemen, door bijvoorbeeld een continuïteitsplan op te stellen. Het doel van dit continuïteitsplan is het onafgebroken gebruik veilig stellen. De calamiteit bij de cloud- of SaaS-leverancier moet zo min mogelijk gevolgen hebben voor de bedrijfsprocessen van de afnemer.

Neem minimaal de volgende onderwerpen in een contract op:

  • dat de data altijd eigendom blijft van de gemeente en in een vastgesteld formaat verstrekt wordt in bepaalde omschreven situaties;
  • broncode-escrowregeling zodat het gebruik, toegang, onderhoud en doorontwikkeling van de software wordt gewaarborgd;
  • exitstrategie (exitplan), voor het geval dat de leverancier niet bevalt of niet meer kan leveren.

Meer informatie

Koppelingen tussen vertrouwde netwerken en niet-vertrouwde netwerken moeten bij voorkeur op de volgende manier worden beveiligd:

  • Kanaalencryptie door middel van een PKIoverheid-SSL certificaat
  • Apparaat authenticatie door middel van een PKIoverheid certificaat
  • Filtering op basis van IP-nummers
  • Scheiding van netwerken met verschillende beveiligingsniveaus
  • Indringerdetectie
  • (Technische) logging

Meer informatie

Lees de volgende operationele BIG-producten: