DSGO.Basis: Als een partij een abonnement wil aanbieden in het DSGO dan MOET de partij dit mogelijk maken met een /subscriptions endpoint

DSGO.Basis: Als een partij een abonnement wil gebruiken in het DSGO dan MOET de partij notificaties kunnen ontvangen op een webhook url

DSGO.Basis: Parties MUST validate that all received API calls conform to the DSGO trust framework

DSGO.Basis: Parties MUST validate that all responses to API calls conform to the DSGO trust framework

DSGO.Basis: Parties SHOULD limit API calls to include only a reasonably sized amount of data

DSGO.Basis: Parties MUST NOT include HTTP bodies in GET or DELETE requests

DSGO.Basis: Parties MAY include query options for functionalities such as filter, sort, and page in their API endpoint as defined in OData 4.01

DSGO.Basis: Parties MUST reject any requests that contain unsupported url parameters with a 501 Not Implemented as defined in OData 4.01

DSGO.Basis: Parties MUST make caching explicit to API users

DSGO.Basis: Parties MUST include the following headers in the API response when it is not cacheable:
cache-control: no-store
pragma: no-cache

DSGO.Basis: Parties MUST include the following headers in the API response when it is cacheable:
cache-control: max-age=31536000
Note: max-age MAY vary

DSGO.Basis: Parties MUST provide only public features to a successful GET request to the /capabilities endpoint, which does not include an access token

DSGO.Basis: Parties MUST validate that a GET request to the /capabilities endpoint includes the Authorization header according to RFC 6750 and contains a valid access token, when returning restricted features

Autorization registers MUST provide delegation evidence via the /delegation endpoint

If data entitled parties wish to provide delegation evidence, they MUST provide delegation evidence via the /delegation endpoint

Parties MUST have a webhook url before obtaining a subscription

If a party has a subscription, they MUST support a notification object

The trust framework catalogue MUST validate that the HTTP body of a GET request to the /parties endpoint contains the parameters as defined in the table below

The trust framework catalogue MUST validate that the HTTP body of a GET request to the /parties endpoint contains at least a single parameter.

DSGO.Basis: Data service providers MUST define subscriptions for events in accordance to the subscription object, when implementing a subscription

DSGO.Basis: Data service providers MUST define events for their subscriptions in accordance to the events object, when implementing a subscription

DSGO.Basis: Data service providers MUST include a list of subscription resources available for the data service consumer in a response to a successful GET calls to the /subscriptions endpoint

DSGO.Basis: Data service providers MUST provide a count of the number of subscriptions included, in the count parameter, in the response to a successful GET calls to the /subscriptions endpoint

DSGO.Basis: Data service providers MUST validate that the HTTP body of a POST request to a /subscriptions endpoint contains the following parameters, with content as defined in the subscription object:

• resource_type

• start_date (optional)

• end_date (optional)

• event_type

• webhook_url

DSGO.Basis: Data service providers MUST validate that a POST request to /subscriptions endpoint complies with their data service specific subscription requirements

DSGO.Basis: Data service providers MUST respond with a 200 OK to a successful GET call to a /subscriptions/{id} endpoint

DSGO.Basis: Data service providers MUST include the requested subscription object in the HTTP body of the response to a successful GET call to the /subscriptions/{id} endpoint

DSGO.Basis: Data service providers MUST validate that the {id} of a DELETE request to a /subscriptions/{id} is valid, exists and is available to the data service consumer

DSGO.Basis: Data service providers MUST validate that the subscription object being deleted complies with their data service specific subscription requirements

DSGO.Basis: Data service providers MUST respond with a 200 OK to a successful DELETE call to a /subscriptions/{id} endpoint

DSGO.Basis: Data service providers MUST NOT include an HTTP body in the response to a successful DELETE call to the /subscriptions/{id} endpoint

DSGO.Basis: Data service providers MUST set the “status" of subscription/{id} to "inactive" in response to a successful DELETE call to the /subscriptions/{id} endpoint

DSGO.Basis: Data service providers MUST validate that the HTTP body of a POST request to a /subscriptions/{id}/test endpoint is empty

DSGO.Basis: Data service providers MUST validate that the {id} of a POST request to a /subscriptions/{id}/test is valid, exists and is available to the data service consumer

DSGO.Basis: Data service providers MUST respond with a 202 Accepted to a successful POST call to a /subscriptions/{id}/test endpoint

DSGO.Basis: Data service providers MUST NOT include an HTTP body in the response to a successful POST call to the /subscriptions/{id}/test endpoint

DSGO.Basis: Data service providers MUST trigger the sending of a notification with “eventType":“Test" to the subscription’s webhook url in response to a successful POST call to the /subscriptions/{id}/test endpoint

DSGO.Basis: Parties MUST validate that a POST request to a /token endpoint contains the parameters as described in the table below

DSGO.Basis: Parties MUST validate the client credentials in the client_assertion received in a POST to a /token endpoint, by comparing the client_id to the iss and sub claim in the client_assertion and the subject_name of the QSEAL used to sign the client_assertion

DSGO.Basis: Parties MUST include an access token as described in the table below in the HTTP payload in a response to a successful POST request to a /token endpoint

DSGO.Basis: Parties MUST NOT issue refresh tokens

DSGO.Basis: Parties MUST validate that a POST request to a /token/revoke endpoint contains the parameters as described in the table below

DSGO.Basis: Parties MUST validate the client credentials in the client_assertion received in a POST to a /token/revoke endpoint

DSGO.Basis: Parties MUST respond with a 200 OK to a successful POST call to a /token/revoke endpoint

DSGO.Basis: Parties MUST respond with a 200 OK to a POST call to a /token/revoke endpoint containing an invalid access token

DSGO.Basis: Parties MUST no longer accept the revoked the access token after a 200 OK response is responded

De Beheerorganisatie DSGO MOET het DSGO logo aanbieden aan deelnemers en gebruikers van het DSGO

De Beheerorganisatie DSGO MOET zelf herkenbaar zijn door het DSGO logo te gebruiken in haar aangeboden stelselvoorzieningen, tooling en communicatie

DSGO.Basis: Partijen MOGEN het DSGO merk, naam en logo wat past bij haar rol gebruiken om zichtbaar te maken dat ze een rol in het DSGO invullen

DSGO.Basis: Partijen MOETEN bij het gebruik van het DSGO merk, naam en logo wat past bij haar rol dit conform onderstaande richtlijnen gebruiken

DSGO.Basis: Als een Partij een interface aanbiedt voor een door een mens geïnitieerde datadienst, dan ZOU het DSGO logo wat past bij haar rol gebruikt MOETEN worden in deze interfaces

DSGO.Basis: Partijen MOETEN uitsluitend standaard HTTP-operaties ondersteunen (GET, PUT, POST, PATCH, DELETE)

DSGO.Basis: Partijen MOGEN NIET de state van de client bij houden

DSGO.Basis: Partijen MOETEN data als resources beschikbaar stellen in een datadienst

DSGO.Basis: Partijen MOETEN resources een zelfstandig naamwoord in het meervoud als naam geven

DSGO.Basis: Partijen MOETEN bij het ontvangen van een HTTP-verzoek antwoorden met (onder andere) een statuscode die het resultaat van het verzoek aangeeft

DSGO.Basis: Partijen MOETEN geschikte HTTP-statuscodes ondersteunen die passen bij de dienst. Tenminste de volgende: 2XX, 4XX en 5XX

DSGO.Basis: Partijen ZOUDEN de standaard foutmeldingen van de HTTP 400 en 500 statuscode reeksen MOETEN ondersteunen volgens RFC 9110

DSGO.Basis: Partijen MOETEN zich uniek identificeren wanneer ze betrokken zijn bij een datadienst

DSGO.Basis: Partijen MOETEN andere partijen die betrokken zijn bij een datadienst uniek identificeren

DSGO.Basis: Datadienstaanbieders MOETEN voor haar datadienst bepalen welk type datadienstgebruiker geauthenticeerd wordt en dit vastleggen in de datadienstspecificatie

DSGO.Basis: Als datadienstaanbieders een datadienstgebruiker wil authenticeren als machine namens partij dan MOET een QSeal gebruikt worden als authenticatie-oplossing

DSGO.Basis: Als datadienstaanbieders een datadienstgebruiker wil authenticeren als mens namens partij OF mens namens zichzelf dan MOET haar keuze voor authenticatie-oplossing(en) worden vastgelegd in de datadienstspecificatie

DSGO.Basis: Datadienstaanbieders MOETEN het autorisatiebeleid bepalen voor elke datadienst

DSGO.Basis: Datadienstaanbieders MOETEN hun autorisatiebeleid vastleggen in de toegangscontroleregels van de datadienstspecificatie

DSGO.Basis: Als datadienstaanbieders gebruik maken van een access token dan MOET dit worden gedaan volgens het afsprakenstelsel

DSGO.Basis: Als datadienstaanbieders gebruik maken van een access token dan MOET dit worden vastgelegd in de datadienstspecificatie

DSGO.Basis: Datadienstaanbieders ZOUDEN het voor de datarechthebbende mogelijk MOETEN maken haar rechten over data te delegeren

DSGO.Basis: Als datadienstaanbieders het delegeren van rechten mogelijk maakt in haar datadienst dan MOET dit worden vastgelegd in de datadienstspecificatie

DSGO.Basis: Als datadienstaanbieders gebruik maken van kwalificaties en eigenschappen dan MOET dit worden gedaan volgens het afsprakenstelsel

DSGO.Basis: Als datadienstaanbieders gebruik maken van kwalificaties en eigenschappen dan MOET dit worden vastgelegd in de datadienstspecificatie

DSGO.Basis: Partijen MOETEN een geldig EORI-nummer of KvK-nummer gebruiken als Organisatie ID

DSGO.Basis: Partijen MOETEN een Organisatie ID gebruiken die overeenkomt met eIDAS certificaten die gebruikt worden voor authenticatie, zie Authenticatie voor meer informatie

DSGO.Basis: Partijen MOETEN API endpoints beveiligen met minimaal TLS v1.2

DSGO.Basis: Partijen ZOUDEN API endpoints MOETEN beveiligen met TLS v1.3

DSGO.Basis: Partijen MOETEN API verzoeken die niet beveiligd zijn met TLS v1.2 of TLS v1.3 afwijzen

DSGO.Basis: Partijen MOETEN voor alle interacties gebruik maken van one-way (server only) TLS

DSGO.Basis: Partijen MOETEN bij toepassing van het TLS protocol certificaten gebruiken met een minimale sleutellengte van 2048 bits en maximale geldigheid van twee jaar

DSGO.Basis: Partijen MOETEN verifiëren dat het certificaat waarmee de Basis JWT is getekend uitgegeven en ondertekend is door een certificaatautoriteit op de vertrouwde lijst van DSGO

DSGO.Basis: Partijen MOETEN verifiëren dat het certificaat waarmee Basis JWT is getekend valide is

DSGO.Basis: Partijen MOETEN bij elk verzoek om een access token, de identiteit van de aanvrager authenticeren door de identiteit uit het certificaat te vergelijken met die uit het access token verzoek. Indien deze niet matchen met elkaar, MOET het verzoek worden afgewezen.

DSGO.Basis: Partijen MOETEN bij een access token verzoek de status van een partij binnen het DSGO verifiëren bij de stelselcatalogus

DSGO.Basis: Partijen MOETEN QSeals gebruiken voor het tekenen van JWTs

DSGO.Basis: Partijen MOETEN alle root certificaten voor QSeals van uitgevers op de EU/EEA List of Trusted Lists (LOTL) en PKIO accepteren

DSGO.Basis: Partijen MOETEN een QSEAL gebruiken die overeenkomt met hun Organisatie ID (EORI of KvK-nummer). Zie Identificatie van organisaties voor meer informatie.

DSGO.Basis: Als gedelegeerde datadienstgebruikers een datadienst kunnen afnemen MOETEN datadienstaanbieders in de datadienstspecificatie vaststellen waar delegaties geregistreerd mogen worden

DSGO.Basis: Als de datarechthebbende gebruik wil maken van de mogelijkheid om haar rechten te delegeren dan MOET de datarechthebbende binnen de opties aangeboden in een datadienst bepalen waar haar delegaties geregistreerd worden

DSGO.Basis: Datarechthebbende MOETEN deelnemer zijn van het DSGO om haar eigen delegaties te beheren

DSGO.Basis: De datarechthebbende MOET delegatie bewijs beschikbaar stellen volgens een /delegation endpoint

DSGO.Basis: Als een datadienstaanbieder de mogelijkheid biedt voor de datarechthebbende om zelf haar delegaties te beheren dan MOET de datadienstaanbieder datadienstverzoeken met HTTP header delegation_evidence met een geldige delegationEvidence object accepteren

DSGO.Basis: Partijen MOETEN in Authenticatie JWTs de parameters zoals opgesteld in de onderstaande tabel gebruiken als JWT headers

DSGO.Basis: Partijen MOETEN in Onweerlegbaarheid JWTs de parameters zoals opgesteld in de onderstaande tabel gebruiken als JWT headers

DSGO.Basis: Partijen MOGEN in alle JWTs andere parameters NIET als JWT headers gebruiken

DSGO.Basis: Partijen MOETEN in alle JWTs de JWT claims opstellen zoals beschreven in de onderstaande tabel volgens RFC7519

DSGO.Basis: Partijen MOETEN in alle JWTs alle JWT claims binnen 30 seconden laten verlopen, aantoonbaar door de combinatie van iat en exp claims.

DSGO.Basis: Partijen MOETEN in alle JWTs de JWT claims de iat en exp claims noteren in seconden en MOGEN iat en exp claims NIET noteren in milliseconden

DSGO.Basis: Partijen MOETEN een getekende JWT maar één keer accepteren

DSGO.Basis: Partijen MOETEN een JWT niet accepteren als:

• De handtekening ongeldig is,

• Deze niet aan hen geadresseerd is, op basis van de aud claim,

• Deze niet verlopen is, op basis van de exp claim,

• Deze niet eerder ontvangen is, op basis van de jti claim met inachtneming van de verlooptijd

DSGO.Basis: Partijen MOETEN het RS256 algoritme gebruiken bij het ondertekenen van alle JWTs

DSGO.Basis: Partijen MOETEN alle JWTs ondertekenen als een JSON Web Signature (JWS) zoals beschreven in RFC 7515

DSGO.Basis: Partijen MOETEN alle getekende Onweerlegbaarheid JWTs formatteren volgens JWS Compact Serialisation

DSGO.Basis: Partijen MOETEN voor alle Onweerlegbaarheid JWTs de Protected HTTP Headers opstellen voor ondertekening zoals aangegeven in de sigD JWT header

DSGO.Basis: Partijen MOETEN voor alle Onweerlegbaarheid JWTs de signing input opstellen als: ASCII(BASE64URL(UTF8(JWS Protected Header)) || '.' || BASE64URL(JWS Payload)) || '.' || BASE64URL(Protected HTTP Headers))

DSGO.Basis: Als datadienstaanbieders willen dat elke datadienstverzoek onweerlegbaar is, MOETEN ze dit vastleggen in de datadienstspecificatie

DSGO.Basis: Als datadienstaanbieders onweerlegbare datadienstresponsen aanbied, MOETEN ze dit vastleggen in de datadienstspecificatie

Partijen ZOUDEN een risicoanalyse uit MOETEN voeren

Partijen ZOUDEN passende informatiebeveiligingsmaatregelen MOETEN nemen

Partijen ZOUDEN andere partijen waarmee wordt samengewerkt MOETEN aansporen passende informatiebeveiligingsmaatregelen te nemen

De Beheerorganisatie DSGO MOET het change en release managementproces begeleiden

De Beheerorganisatie DSGO MAG een Request For Change (RFC) voorstel indienen conform het change en release managementproces

De Beheerorganisatie DSGO MOET binnen 2 werkdagen na ontvangst van een RFC voorstel een ontvangstbevestiging sturen aan de indienende partij

De Beheerorganisatie DSGO MOET een RFC voorstel voorbereiden en de voorgestelde aanpassing verder detaileren om de RFC voor te bereiden voor de Change Advisory Board

De Deelnemersraad MOET het advies over RFCs (ontvangen van de CAB) goed- of af keuren

De Change Advisory Board MOET de Deelnemersraad adviseren over RFCs binnen het change en release management proces

Partijen MOGEN een Request For Change (RFC) voorstel indienen conform het change en release managementproces

Als een partij een Request For Change (RFC) voorstel indient, dan MOET dit conform de beschikbare templates

De Beheerorganisatie DSGO MOET haar managementinformatie in lijn met de SLAs voor de Beheerorganisatie DSGO beschikbaar stellen

De Beheerorganisatie DSGO MOET zorgen dat concurrentiegevoelige informatie niet openbaar wordt gemaakt in de managementrapportage

De Beheerorganisatie DSGO MOET het gehele managementrapportageproces begeleiden

Marktvoorzieningen MOETEN hun managementinformatie in lijn met de SLAs voor marktvoorzieningen aanleveren aan de Beheerorganisatie DSGO

Indien de aangeleverde managementinformatie niet klopt, MOET de marktvoorziening dit binnen 5 werkdagen corrigeren

De Beheerorganisatie DSGO MOET een toetredende partij door het gehele toetredingsproces begeleiden

De Beheerorganisatie DSGO MOET een non-disclosure agreement (NDA) tekenen tijdens het toetreden als de toetredende partij hier om vraagt

De Beheerorganisatie DSGO MOET de uitslag van de eerste controle voor alle toetredende partijen binnen een termijn van 5 werkdagen, gerekend vanaf ontvangst van alle benodigde informatie, communiceren met de toetredende partij

De Beheerorganisatie DSGO MOET de uitslag van de rol-gerelateerde validatie voor marktvoorzieningen binnen een termijn van 30 werkdagen, gerekend vanaf ontvangst van alle benodigde informatie, communiceren met de toetredende partij

De Beheerorganisatie DSGO MOET de uitslag van de rol-gerelateerde validatie voor datadienstaanbieders en technisch conform datadienstaanbieders binnen een termijn van 5 werkdagen, gerekend vanaf ontvangst van alle benodigde informatie, communiceren met de toetredende partij

Een toetredende partij MOET het toetredingsproces voor de rol die ze wil vervullen succesvol doorlopen om de door haar geselecteerde rol(len) in te vullen in het DSGO

Een toetredende partij MOET de Deelnameovereenkomst voor de rol die ze wil vervullen tekenen om deelnemer te worden

Een toetredende partij MOET de Overeenkomst technische conformiteit tekenen om technisch conform datadienstaanbieder te worden

Een betrokken partij MOET incidenten direct na ontdekking melden bij de Beheerorganisatie DSGO

Een betrokken partij MOET bij melding van een incident de naam van de verondersteld veroorzakende partij met een onderbouwing van de constatering/vermoeden, datum, tijd, ingeschatte incident classificatie en impact op de datadienst melden

De incidentcoördinator MOET het incidentbeheer proces na de melding van een incident coördineren.

De incidentcoördinator MOET kunnen optreden als een neutrale partij bij het incident

De incidentcoördinator MOET binnen een redelijke termijn een binnengekomen melding beoordelen en een classificatie inschatting maken

De incidentcoördinator MOET het incident beoordelen en legt het classificatie niveau vast

De partij die verantwoordelijk is voor het verhelpen of oplossen van incidenten MOET een incidentmanager beschikbaar stellen

De incidentmanager ZOU voor alle Prioriteit 1 en Prioriteit 2 incidenten 24u per dag, 7 dagen per week beschikbaar MOETEN stellen

De incidentmanager MOET voor een Prioriteit 1 incident een update delen met de incidentcoördinator binnen 2 uur van elke belangrijke update en elke 4 uur bij geen update

De incidentmanager MOET voor een Prioriteit 2 incident een update delen met de incidentcoördinator binnen 2 uur van elke belangrijke update aan het einde van elke werkdag bij geen update

De incidentmanager MOET voor een Prioriteit 3 incident een volledige update delen met de incidentcoördinator aan het einde van elke werkdag

De Beheerorganisatie DSGO MOET voordat het overgaat tot handhaven de belangen van het DSGO, de betrokken partijen en de deelnemers in overweging nemen en het doel van de maatregel afwegen tegen de gevolgen

De Beheerorganisatie DSGO MOET de overtreding beoordelen en legt het classificatie niveau vast

De Beheerorganisatie DSGO MAG een handhavende maatregel (waarschuwing, schorsing of uitsluiting) opleggen bij een overtreding om de vertrouwelijkheid en/of integriteit van het DSGO afsprakenstelsel te beschermen

De Beheerorganisatie DSGO MOET bij een release van het afsprakenstelsel de wijziging van versienummer bepalen

De Beheerorganisatie DSGO MOET releases communiceren middels de versie richtlijnen

De Beheerorganisatie DSGO MOET het uittredingsproces faciliteren voor een uittredende partij

De Beheerorganisatie DSGO MOET binnen 5 werkdagen de intentie tot uittreding van een uittredende deelnemer bevestigen

Een partij MOET het uittredingsproces succesvol doorlopen om uit te treden uit het DSGO

Een marktvoorziening die uittreedt MOET een uittredingsplan opstellen en (na goedkeuring van Beheerorganisatie DSGO) uitvoeren om uit te treden uit het DSGO

Datadienstgebruikers MOETEN deelnemer zijn van het DSGO om het gebruik van een datadienstbroker te registreren

Datadienstgebruikers MOETEN gebruik van een datadienstbroker registeren bij het toetreden tot het DSGO

De stelselcatalogus MOET brokerbewijs beschikbaar stellen volgens een /brokers endpoint

Datadienstaanbieders MOETEN datadienstverzoeken met HTTP header broker_evidence met een geldige brokerEvidence object accepteren

Datadienstbrokers MOETEN enkel data die nodig is om haar diensten uit te voeren (zoals afgesproken met haar klanten) verzamelen

Datadienstbrokers MOETEN enkel data die nodig is om haar diensten uit te voeren (zoals afgesproken met haar klanten) opslaan

Datadienstbrokers MOETEN enkel data verwerken als nodig om haar diensten uit te voeren (zoals afgesproken met haar klanten)

Datadienstbrokers MOETEN data enkel voor redelijke, en proportionele termijnen opslaan

Datadienstbrokers MOETEN data van haar klanten verwijderen wanneer dit wordt aangevraagd

De Beheerorganisatie DSGO MOET de developer portal en de stelselcatalogus binnen het openstellingsvenster van 24 uur per dag voor 365 dagen per jaar beschikbaar stellen aan gebruikers

De Beheerorganisatie DSGO MOET het developer portal en de stelselcatalogus binnen het openstellingsvenster 99% van de tijd beschikbaar stellen, gepland onderhoud telt niet als onbeschikbaarheid

De Beheerorganisatie DSGO MOET het onderhoudsvenster van de developer portal en de stelselcatalogus vastleggen tussen 00:00 en 04:00

De Beheerorganisatie DSGO MOET het onderhoudsvenster van de developer portal en de stelselcatalogus communiceren richting (potentiële) deelnemers en gebruikers van het DSGO

De Beheerorganisatie DSGO MAG gepland onderhoud aan de developer portal en de stelselcatalogus op elke tijdstip uitvoeren als er geen uitval wordt verwacht

De Beheerorganisatie DSGO MOET gepland onderhoud aan de developer portal en de stelselcatalogus communiceren aan partijen die hier hinder van kunnen ondervinden

Datadienstaanbieders MOETEN het openstellingsvenster van de datadienst definiëren en beschikbaar stellen aan datadienstgebruikers

Datadienstaanbieders MOETEN het onderhoudsvenster van de datadienst definiëren en beschikbaar stellen aan datadienstgebruikers

Datadienstaanbieders MOETEN het onderhoudsvenster plannen buiten reguliere kantooruren

Datadienstaanbieders MOGEN gepland onderhoud uitvoeren op elke tijdstip, als er geen uitval wordt verwacht

Datadienstaanbieders ZOUDEN datadiensten binnen het beschikbaarheidsvenster minimaal 95% van de tijd beschikbaar MOETEN stellen aan datadienstgebruikers

Datadienstaanbieders ZOUDEN op 95% van API verzoeken binnen 2 seconden MOETEN reageren binnen het beschikbaarheidsvenster

Datadienstaanbieders ZOUDEN op 99% van API verzoeken binnen 5 seconden MOETEN reageren binnen het beschikbaarheidsvenster

Datadienstaanbieders ZOUDEN ten minste 100 API verzoeken gelijktijdig MOETEN kunnen verwerken binnen het beschikbaarheidsvenster

Datadienstaanbieders ZOUDEN op een passende frequentie een back-up MOETEN maken van data belangrijk voor de datadienst

Datadienstaanbieders ZOUDEN de back-ups MOETEN opslaan voor een passende periode

Datadienstaanbieders ZOUDEN bereikbaar MOETEN zijn voor ondersteuning via e-mail

Datadienstaanbieders ZOUDEN binnen een werkdag na ontvangst van een vraag, verzoek of klacht MOETEN aangeven dat hiervan kennis is genomen

Datadienstaanbieders ZOUDEN binnen vijf werkdagen na ontvangst van een vraag, verzoek of klacht deze MOETEN beantwoorden of oplossen

Marktvoorzieningen MOETEN diensten binnen het openstellingsvenster van 24 uur per dag voor 365 dagen per jaar beschikbaar stellen aan gebruikers

Marktvoorzieningen MOETEN het onderhoudsvenster van de dienst, inclusief definiëring van de datum, tijd en getroffen dienst(en), ten minste 10 werkdagen voor het onderhoud aankondigen aan de betrokken partijen

Marktvoorzieningen MOETEN het onderhoudsvenster plannen op de nachten van vrijdag op zaterdag en van zaterdag op zondag, van 00:00-5.59u

Marktvoorzieningen MOGEN gepland onderhoud uitvoeren op elke tijdstip, als er geen uitval wordt verwacht

Marktvoorzieningen MOETEN diensten binnen het beschikbaarheidsvenster van minimaal 99% van de tijd beschikbaar stellen aan gebruikers

Datadienstaanbieders MOETEN alle DSGO.Basis afspraken volgen

Technisch conforme datadienstaanbieders MOETEN alle DSGO.Basis afspraken volgen

Partijen MOGEN NIET bilaterale afspraken maken die een conflict oplevert met de DSGO.Basis afspraken van het DSGO