Hoofdinhoud

Deze Serviceniveau-overeenkomst (SNO) is de vastlegging van het niveau van de service  die Logius levert voor Stelselcatalogus aan Afnemers. De SNO is een bijlage van de opdracht, Algemene Voorwaarden Logius en Aansluitvoorwaarden Stelselcatalogus en daardoor een aanvulling op deze genoemde voorwaarden die gelden tussen Logius en Afnemers.

Versie: 1.0
Ingangsdatum: 15 juni 2026

1. Serviceniveau-overeenkomst 

Doelen

Deze SNO geeft de Afnemers duidelijkheid over het niveau van de dienstverlening met de volgende doelen:

  • De dienstverlening continu afstemmen op de veranderende behoeften van de opdrachtgever om een optimale dienstverlening te verlenen; 
  • Misinterpretatie over de dienstverlening effectueren; 
  • Afspraken maken over de serviceverlening om de opdrachtnemer in staat te stellen de dienstverlening beter op bestaande en mogelijke nieuwe behoeften af te stemmen.

Wijzigen van de SNO

Deze SNO wordt, indien nodig, door Logius gewijzigd bij een nieuwe release van Stelselcatalogus of bij veranderde serviceniveau wensen. De gewijzigde SNO wordt na operationele afstemming met direct betrokkenen ter vaststelling aan de Product Manager aangeboden. Logius is voornemens om éénmaal per jaar een ketenoverleg te organiseren om de service te toetsen en te valideren of de SNO nog voldoet.

Definities

In deze paragraaf definiëren we termen die we in deze SNO gebruiken en die nog niet zijn gedefinieerd in de Algemene voorwaarden of Aansluitvoorwaarden.

Term/Afkorting Beschrijving
Servicetijd De periode gedurende welke de afnemers gebruik kunnen maken van (alle onderdelen van) de voorziening.
Beschikbaarheid  De mate waarin de voorziening toegankelijk is voor de afnemers.

Beschikbaarheids-

percentage

De mate waarin Logius garanties afgeeft voor de beschikbaarheid, uitgedrukt in een percentage.
Continuïteitsbeheer Het in kaart hebben van objecten/configuraties en services waarvoor Logius verantwoordelijk is. Verstrekken van accurate informatie hierover om andere managementprocessen te ondersteunen.
Baseline Informatiebeveiliging Overheid (BIO) De Baseline Informatiebeveiliging Overheid is het basisnormenkader voor informatiebeveiliging binnen alle overheidslagen (Rijk, gemeenten, provincies en waterschappen). Had voorheen iedere overheidslaag zijn eigen baseline, nu is er met gezamenlijke inspanning 1 BIO voor de gehele overheid.
AVG Algemene verordening gegevensbescherming (AVG).
Incidentbeheer Een incident is elke gebeurtenis die afwijkt van de (verwachte) standaardwerking van voorziening. Dit kan dus een verstoring zijn in de beschikbaarheid van de voorziening, maar ook dat een bepaalde functie binnen het systeem (opeens) niet meer werkt zoals verwacht.

Leeswijzer

  • Hoofdstuk 2 beschrijft de serviceniveaus van de voorziening. Dit zijn prestatie-indicatoren en bijbehorende normen voor de beschikbaarheid, performance, continuïteit en beveiliging van de voorziening. Verder is aan het begin van dit hoofdstuk een verwijzing opgenomen naar de beschrijving van de voorziening;
  • Hoofdstuk 3 beschrijft de serviceniveaus van de (beheer)werkzaamheden die Logius uitvoert. Dit zijn prestatie-indicatoren en bijbehorende normen bij beheerprocessen;
  • Hoofdstuk 4 beschrijft de communicatie tussen de gebruikers/afnemers en Logius met betrekking tot het voorziening.

 

2. Serviceniveau Stelselcatalogus

Dit hoofdstuk beschrijft de prestatie-indicatoren betreffende Stelselcatalogus. Ten aanzien van capaciteit, performance en betrouwbaarheid zijn op dit moment geen vaste afspraken gemaakt met de betrokken partijen.

2.1 Beschrijving Stelselcatalogus

De Stelselcatalogus is een catalogus die inzicht en overzicht biedt in de verschillende soorten metadata binnen het landschap van overheidsgegevens. Binnen de catalogus zijn verschillende typen metadata (begrippenkaders en informatiemodellen) gekoppeld tot één geheel door relaties te leggen tussen de losse onderdelen van deze metadata. Dit geheel heet een Knowledge Graph. De catalogus stelt gebruikers in staat deze Knowledge Graph eenvoudig te doorzoeken, wat het makkelijker maakt om inzichten te verkrijgen uit de data.

2.2 Servicetijden, Beschikbaarheid en Continuïteitsbeheer 

2.2.1 Gegarandeerde Servicetijd en beschikbaarheid

De onderstaande Servicetijd betreft uitsluitend Stelselcatalogus zelf. Beschikbaarheid van netwerk koppelingen en beschikbaarheid van faciliteiten bij Afnemers vallen buiten deze garantie. Van Afnemers wordt verwacht dat zij hun systemen ook buiten kantoortijden actief hebben.

Prestatie-indicator Toelichting Norm Minimaal te realiseren
Servicetijden Tijdvenster waarbinnen de dienst kan worden afgenomen. 24 uur, 7 dagen per week; behoudens gepland onderhoud (zie paragraaf 2.2.3) en behoudens gevolgen van incidenten die ontstaan zijn buiten ondersteuningstijden (zie paragraaf 3.1.1) 98%
Beschikbaarheid Tijdvenster waarbinnen gebruikersondersteuning wordt aangeboden en het functioneren van de dienst actief wordt bewaakt. Servicevenster waarin gebruikersondersteuning wordt aanboden is maandag tot en met vrijdag van 08.00 tot 17.00 n.v.t.

Het beschikbaarheidspercentage wordt per kalendermaand berekend door de formule: feitelijke beschikbaarheid in uren / norm beschikbaarheid in uren x 100%.

2.2.2 Continuïteitsbeheer

De continuïteit van Stelselcatalogus zelf (dus het percentage in voorgaande paragraaf) wordt mede geborgd door de inrichting van de technische infrastructuur. Apparatuur is redundant uitgevoerd en er vindt synchronisatie van gegevens plaats. Tevens vindt (pro)actieve monitoring plaats op diverse plekken binnen de Stelselcatalogus. Hiermee wordt geborgd dat technische problemen meteen worden opgemerkt en er actie op kan worden genomen.

De continuïteit van de Stelselcatalogus is tevens afhankelijk van de beschikbaarheid van de eigen technische voorzieningen van de aangesloten Afnemers. Deze onderdelen van de keten vallen buiten de reikwijdte van deze SNO.

Het doel van Continuïteitsbeheer is:

  • Het verminderen van het effect van een verstoring of calamiteit op de bedrijfsprocessen binnen de Stelselcatalogusketen;
  • Het zekerstellen dat de dienstverlening na een verstoring of calamiteit zo snel mogelijk wordt hersteld;
  • Het voorkomen van verstoringen of calamiteiten door het continu uitvoeren van risicoanalyses gericht op het inventariseren van potentiële bedreigingen en door het treffen van noodzakelijke preventieve maatregelen;
  • Het jaarlijks testen van het continuïteitsplan door het uitwijkplan te testen en de evaluatie daarvan als verbeterplan hanteren voor de volgende continuïteitstesten.

    Voor Stelselcatalogus gelden de volgende waarden: 
    - RPO (Recovery Point Objective), ofwel het Maximaal toegestane dataverlies;
    - RTO (Recovery Time Objective), ofwel de Maximaal toegestane onbeschikbaarheid

Voorziening  Eis  Waarde 
Stelselcatalogus RPO 24 uur
RTO 48 uren

Er zijn geen eisen vanuit de opdrachtgever gesteld voor RTO en RPO. In deze tabel zijn de haalbare waardes volgens Logius weergegeven.

2.2.3 Gepland onderhoud

Voor het actueel houden van Stelselcatalogus en onderliggende technische componenten, vindt regelmatig onderhoud plaats. Omdat de Stelselcatalogus redundant is uitgevoerd, zullen gebruikers geen impact ervaren bij regulier onderhoud.

Overig onderhoud wat mogelijk de Stelselcatalogus kan raken, wat niet in de verwachting ligt, wordt altijd van tevoren aangekondigd door een publicatie op  https://www.logius.nl/storing-en-onderhoud en de Logius app, zie ook https://www.logius.nl/logius-app

2.3 Beveiliging

Stelselcatalogus is gebouwd, ingericht en wordt beheerd volgens de richtlijnen van:

  • De architectuur richtlijnen van Logius;
  • De Baseline Informatiebeveiliging Overheid; 
  • Nationaal Cyber Security Centrum (NCSC). Beveiligingsrichtlijnen voor webapplicaties.

Sinds 25 mei 2018 is de Algemene verordening gegevensbescherming (AVG) van toepassing. Dat betekent dat in de hele Europese Unie (EU) dezelfde privacywetgeving geldt.

Beveiligingsincidenten worden binnen Logius altijd opgepakt als Prioriteit 1 incident conform paragraaf 3.3.

 

3. Serviceniveau beheer Logius

3.1 Gebruikersondersteuning en beheer

Voor ondersteuning bij het gebruik van Digimelding is Logius bereikbaar voor vragen, verstoringen, fouten, verzoeken en klachten betreffende de dienstverlening. Dit kan via het contactformulier of het telefoonnummer van Logius.

Logius is op werkdagen van 8.00 – 17.00 uur bereikbaar via:

Mochten er nieuwe behoeften zijn, kunnen deze ingebracht worden via de Business Consultant van Logius.

3.1.1 Gegarandeerde servicetijden

Gedurende de gegarandeerde servicetijden, wordt actief beheer gevoerd over Stelselcatalogus door Logius. 

Prestatie-indicator Norm
Gegarandeerde servicetijden Op werkdagen van 8.00 – 17.00 uur

3.1.2 Inhoud van Stelselcatalogus

De kwaliteit en inhoud van de begrippen en begrippenkaders die data-aanbieders maken en/of publiceren via de Stelselcatalogus zijn volledig de verantwoordelijkheid van de betreffende data-aanbieders.

3.2 Incidentbeheer

Een incident is elke gebeurtenis die afwijkt van de (verwachte) standaardwerking van Stelselcatalogus. Dit kan dus een verstoring zijn in de beschikbaarheid van Stelselcatalogus, maar ook dat een bepaalde functie binnen het systeem niet meer werkt zoals verwacht.

Het doel van het Incidentbeheer proces is:

  • Borgen dat betrokken partijen bij een storing in Stelselcatalogus direct geïnformeerd worden;
  • Bij een (dreigende) verstoring zo snel mogelijk de gevolgen hiervan wegnemen, zodat de dienstverlening volgens de afgesproken niveaus kan plaats vinden;
  • Borgen dat bij verstoringen met grote impact (calamiteiten) de benodigde urgentie en betrokkenheid gewaarborgd is.

Logius administreert de incidenten en communiceert met de betrokkenen. Logius bewaakt de voortgang van de oplossing en zorgt dat de betrokkenen op de hoogte zijn van de actuele voortgang. 

3.2.1 Urgentie en impact

Om de werkzaamheden rond incidenten met de juiste prioriteiten efficiënt en effectief uit te kunnen voeren bekijkt Logius eerst wat de urgentie en impact van het incident is. Op basis daarvan bepaalt Logius, indien van toepassing in overleg met de aanmelder, de streeftijd voor het bieden van een oplossing.

Met urgentie wordt bedoeld in welke mate een directe oplossing nodig is of dat enig uitstel mogelijk is. 

Urgentie
Hoog

Een directe oplossing is noodzakelijk en duldt geen uitstel. 

 

Voorbeelden: 

  • Stelselcatalogus functioneert in zijn geheel niet;
  • Er spelen veiligheidsrisico’s of er zijn concrete beveiligingsincidenten.

     
Midden  Uitstel is beperkt mogelijk zodat een oplossing buiten kantooruren gerealiseerd kan worden.
Laag Uitstel is mogelijk. Het moment van herstel wordt in overleg met de betrokkenen bepaald. Uit dit overleg kan blijken dat de urgentie hoger is dan initieel ingeschat was.

Met impact wordt bedoeld wat de mate van afwijking van de standaard werking van Stelselcatalogus is waardoor het werkproces verstoord wordt.

Impact
Hoog

Voorbeelden:

  • De Stelselcatalogus is niet beschikbaar voor de Afnemers.
  • Een beveiligingsincident heeft altijd impact Hoog.

     
Midden 

Stelselcatalogus functioneert, maar het is niet mogelijk om wijzigingen aan te brengen of begrippen te beheren.

 

Laag

Stelselcatalogus werkt niet zoals verwacht, maar de impact is niet Hoog of Midden.

 

3.2.2 Oplostijd

Op basis van de combinatie urgentie en impact wordt de prioriteit voor oplossen bepaald met onderstaande tabel.

    Impact
    Hoog Midden Laag
Urgentie Hoog 1 2 3
Midden 2 3 3
Laag 3 3 3

Voor de drie prioriteiten is de oplostijd waarnaar gestreefd wordt weergegeven in onderstaande tabel.

Prestatie-indicator Norm Minimaal te realiseren per maand
Oplostijd incident met prioriteit 1 4 uur gedurende werkdagen van 8:00 – 17:00 uur 90%
Oplostijd incident met prioriteit 2 12 uur gedurende werkdagen van 8:00 – 17:00 uur 90%
Oplostijd incident met prioriteit 3 24 uur gedurende werkdagen van 8:00 – 17:00 uur 90%


Het oplostijd percentage wordt per kalendermaand berekend door de formule: aantal opgeloste incidenten / aantal geopende incidenten x 100%.

Om het behalen van de oplostijd bij een prioriteit 1 incident te kunnen garanderen, wordt het incident altijd doorgezet naar de stand-by manager van Logius. Deze formeert een (of complementeert het bestaande) oplosteam voor het betreffende prioriteit 1 incident.

3.3 Calamiteitenbeheer 

Er is sprake van een calamiteit als, door wat voor oorzaak dan ook, bij een prioriteit 1 incident geen oplossing in zicht is na 4 uur.

Zodra sprake is van een calamiteit wordt door de Logius calamiteitenmanager een calamiteitenteam geformeerd dat samen met het oplosteam verantwoordelijk is voor herstel van de dienstverlening en voor interne en externe communicatie. 

De calamiteitenmanager heeft meer (hiërarchische) bevoegdheden dan de stand-by manager. Stand-by managers zijn 24/7 bereikbaar in het geval van een calamiteit.

Na herstel van de dienstverlening wordt de calamiteit altijd door Logius geëvalueerd om herhaling waar mogelijk te voorkomen.

3.4 Behoeftenbeheer / wijzigingenbeheer

Met behoefte wordt bedoeld een wens van Afnemers, Leveranciers, Opdrachtgevers en/of interne medewerkers ten aanzien van (het beheer van) Stelselcatalogus, die kan leiden tot functionele en/of niet-functionele wijzigingen van Stelselcatalogus.

Doel van het behoefte beheer/wijzigingenbeheer is de kwaliteit van de producten en diensten van Logius voor de klant continu te verhogen door:

  • Zo snel, efficiënt, professioneel en klantvriendelijk mogelijk te komen tot inventarisatie van behoeften die spelen bij klanten, leveranciers, opdrachtgevers en/of interne medewerkers en om te zetten tot verzoeken voor productwijzigingen. Honorering van de wens is afhankelijk van o.a. urgentie, impact, tijd, kosten;
  • Het planmatig en gecontroleerd doorvoeren of juist onderbouwd niet doorvoeren van productwijzigingen;
  • Een goed voorbereidend input proces te vormen voor het releasebeheer.

 

De werkwijze is samengevat als volgt:

  • Behoeften ten aanzien van Stelselcatalogus kunnen worden ingediend via het contactformulier op www.logius.nl onder tab “Contact”; 
  • Ook kunnen deze worden ingebracht  via de Product Owner en de Business Consultant;
  • De Product Owner stemt altijd af met de indiener van de behoefte en zet het door naar de interne Logius organisatie om de eventuele impact van mogelijke wijzigingen in kaart te brengen; 
  • Indien de wijziging daadwerkelijk moet worden doorgevoerd wordt deze aan de Backlog toegevoegd;
  • In het geval dat de behoefte uiteindelijk moet leiden tot aanpassingen in de Stelselcatalogus software, zal de voorgestelde wijziging worden gerealiseerd door het Development team van Logius.

Tenslotte wordt er voor wijzigingsbeheer het Semantic Version Model toegepast.

3.5 Release en onderhoudsbeheer

Releasebeheer waarborgt dat nieuwe releases van de voorziening met de afgesproken kwaliteit in productie worden genomen. Aangezien de voorziening redundant is uitgevoerd, zullen gebruikers geen impact ervaren bij releases en onderhoud.

 

4. Communicatie

4.1 SNO overleg

Op verzoek van stakeholders kan er op ad-hoc basis een overleg over de SNO gevoerd worden met stakeholders. Deze zal gecoördineerd en gepland worden door de Logius Servicemanager.

4.2 Rapportage

Er wordt niet gerapporteerd over de afspraken in deze SNO richting afnemers. Echter, wordt er wel intern gerapporteerd en geëvalueerd op bovenstaande serviceniveaus.

4.3 Storingen

De status van een storing van Stelselcatalogus, en indien mogelijk een prognose van de storingsduur, wordt vermeld op https://www.logius.nl/storing-en-onderhoud. Daarnaast worden storingen en onderhoud  ook weergegeven in de Logius App. Zodra de dienstverlening is hersteld, wordt dit op deze pagina afgemeld.

Tevens stuurt het Logius een e-mail naar de contactpersonen die zijn aangegeven op het aanvraagformulier voor aansluiten op Stelselcatalogus, of die zich hebben aangemeld via het aanmeldformulier op dezelfde webpagina.

Meer informatie over de Logius app vindt u via https://www.logius.nl/logius-app.

4.4 Gepland onderhoud

Gepland onderhoud van Stelselcatalogus wordt zowel op de website van Logius gepubliceerd als de Logius App.

Versiegeschiedenis

Versie 1.0 (15 juni 2026)
Eerste versie

Eerdere versies
Niet van toepassing