Offertevoorwaarden Digipolis Antwerpen

Belangrijk!

Bij elke offerte voeg je onderstaande documenten ingevuld toe.

De opdrachtgever (laatst gewijzigd op 19/8/2021)

Wie zijn we? Voor wie werken we?

De opdracht gebeurt in naam en voor rekening van AG Digipolis Antwerpen, autonoom gemeentebedrijf met zetel te Generaal Armstrongweg 1, 2020 Antwerpen, met ondernemingsnummer 0751.541.350 en BTW nr. BE 751.541.350

AG Digipolis Antwerpen is een autonoom gemeentebedrijf opgericht overeenkomstig het Decreet Lokaal Bestuur en heeft van haar leden de opdracht gekregen tot het verrichten van werkzaamheden in het gemeenschappelijk belang, ten bate van alle leden, in het bijzonder:

alle aspecten van informatietechnologie en haar toepassingen
alle aspecten rond innovatie, de digitale transformatie van de processen van de groep stad Antwerpen
Voor meer info zie https://www.digipolisantwerpen.be

Digipolis treedt voor deze opdracht op als aankoopcentrale in de zin van artikel 2, 6°, a) van de Wet op Overheidsopdrachten (hierna ‘WOO’).

Overeenkomstig haar statuten kan Digipolis gelijkaardige prestaties leveren voor andere publieke instellingen en ondernemingen, voor zover deze activiteiten aansluiten op de dienstverlening die ten behoeve van de entiteiten van de groep stad Antwerpen wordt ontwikkeld, en in zoverre deze activiteiten een bijkomstig karakter hebben. Voor deze prestaties kan Digipolis een kostendekkende vergoeding vragen.

Overeenkomstig de artikelen 43, §2 en 47 WOO kunnen volgende aanbestedende overheden rechtstreeks gebruik maken van deze raamovereenkomst:

- de leden van Digipolis, zijnde:

Stad Antwerpen,
AG Stedelijk Onderwijs Antwerpen,
Zorgbedrijf Antwerpen,
Politiezone Antwerpen, met inbegrip van alle aan Politiezone Antwerpen toegewezen taken in het kader van de interzonale samenwerking met andere politiezones;
Brandweerzone Antwerpen; OCMW, VZW integratie en inburgering Antwerpen;
AG Culturele Instellingen Antwerpen/Erfgoed;
Instellingen die vallen onder de rechtspersoonlijkheid van de stad Antwerpen;
Instellingen met een afzonderlijke rechtspersoonlijkheid die door de stad Antwerpen belast zijn met een bepaalde taak van gemeentelijk belang; ZNA-Groep; Zorgbedrijf Antwerpen-groep; Beschut Wonen Antwerpen; AG Vespa; AG Energiebesparingsfonds Antwerpen, AG Mobiliteit en Parkeren;

- overheden, overheidsondernemingen, instellingen of organisaties, al dan niet met rechtspersoonlijkheid, zoals, maar niet beperkt tot Havenbedrijf Antwerpen (Port of Antwerp), The Beacon vzw, Bluechem vzw, Woonhaven, enz. die een samenwerkingsovereenkomst afgesloten hebben met Digipolis.

De opdrachtnemer is ertoe gehouden om op grond van de overeenkomst de diensten die aan Digipolis worden aangeboden onder dezelfde voorwaarden aan voormelde aanbestedende overheden, entiteiten, instellingen en agentschappen aan te bieden.

Het begrip aanbestedende overheid kan zowel betrekking hebben op Digipolis als op de hiervoor bedoelde aanbestedende overheden.

De opdrachtnemer is gehouden om prestaties te verrichten voor de aanbestedende overheden, wanneer zij daarom verzoeken. De aanbestedende overheden beslissen autonoom of zij toetreden tot de raamovereenkomst.
Digipolis is niet aansprakelijk voor een gebeurlijk gebrekkige gunning of uitvoering van de deelopdrachten/bestellingen, noch langs de zijde van de aanbestedende overheid, noch langs de zijde van de opdrachtnemer.

De aanbestedende overheden zijn dus als enige verantwoordelijk voor de betaling van de opdrachtnemer binnen elke deelopdracht. Digipolis is niet aansprakelijk voor achterstallige betalingen of vervallen intresten die de aanbestedende overheden verschuldigd zijn in het kader van de uitvoering van een deelopdracht.

Aard en wijze van gunning

Onderhandelingsprocedure zonder bekendmaking

AG Digipolis Antwerpen behoudt altijd het recht om de procedure stop te zetten en niet over te gaan tot gunning van de opdracht.

Met de indiening van zijn offerte verklaart de inschrijver zich akkoord met alle bepalingen en voorwaarden uit deze offerte-vraag.

De inschrijver verklaart zich met de inschrijving bovendien akkoord dat de bepalingen en voorwaarden in de offerte-vraag steeds voorrang zullen hebben bij elke mogelijke tegenstrijdigheid tussen bepalingen in deze offerte-vraag en de ingediende offerte.

Toepasselijke Wetgeving

De Belgische regelgeving betreffende overheidsopdrachten voor werken, leveringen en diensten is van toepassing op deze opdracht. Behoudens afwijkingen zijn de volgende bepalingen en voorwaarden van toepassing:

Wet van 17 juni 2016 inzake overheidsopdrachten en latere wijzigingen (‘WOO’).
Koninklijk besluit van 18 april 2017 betreffende plaatsing overheidsopdrachten klassieke sectoren, en latere wijzigingen (‘KB Plaatsing’).
Koninklijk besluit van 14 januari 2013 tot bepaling van de algemene uitvoeringsregels van de overheidsopdrachten, en latere wijzigingen (‘KB Uitvoering’).
Wet van 17 juni 2013 betreffende de motivering, de informatie en de rechtsmiddelen inzake overheidsopdrachten, bepaalde opdrachten voor werken, leveringen en diensten en concessies, en latere wijzigingen (‘Wet Rechtsbescherming’).
De verordening (EU) 2016/679 van het Europees Parlement en de Raad van 27 april 2016 betreffende de bescherming van natuurlijke personen in verband met de verwerking van persoonsgegevens en betreffende het vrije verkeer van die gegevens en tot intrekking van Richtlijn 95/46/EG.
Wet van 30 juli 2018 betreffende de bescherming van natuurlijke personen met betrekking tot de verwerking van persoonsgegevens.
Opvolging van de Verordening (EU) 2018/1807 van het Europees Parlement en de Raad van 14 november 2018 inzake een kader voor het vrije verkeer van niet-persoonsgebonden gegevens in de Europese Unie.
Wet van 4 augustus 1996 betreffende het welzijn van de werknemers bij de uitvoering van hun werk, meer bepaald hoofdstuk Vbis. Bijzondere bepalingen betreffende geweld, pesterijen en ongewenst seksueel gedrag op het werk.
Het Algemeen Reglement voor de Arbeidsbescherming (ARAB), Welzijnswet en Codex over het welzijn op het werk;
Regelgeving met betrekking tot LIMOSA (Sinds 1 april 2007 moeten buitenlandse werkgevers een limosa-aangifte doen indien zij tijdelijk of gedeeltelijk werknemers in België tewerkstellen). Alle informatie is beschikbaar via www.limosa.be.
De opsomming hierboven “toepasselijke reglementering” is niet limitatief. De inschrijving wordt geacht, alle van toepassing zijnde bepalingen, te kennen en in overeenstemming met de van toepassing zijnde regelgeving te handelen met betrekking tot deze overheidsopdracht.
De inschrijver wordt geacht de wetgeving die van toepassing is op onderhavige opdracht te kennen. De elektronische versie van deze teksten kan worden geraadpleegd op:
http://www.publicprocurement.be of http://www.ejustice.just.fgov.be/loi/loi.htm

Op de overeenkomst is het Belgische recht exclusief van toepassing. Elk geschil over de geldigheid, de uitlegging of de uitvoering van de Overeenkomst zal, bij gebreke aan een minnelijke regeling, definitief worden beslecht door de hoven en rechtbanken van het gerechtelijk arrondissement Antwerpen, afdeling Antwerpen.

Andere relevante wettelijke en reglementaire bepalingen

Illegaal verblijvende onderdanen

Wanneer de Opdrachtnemer of onderaannemer het in artikel 49/2, vierde lid, van het Sociaal Strafwetboek bedoelde afschrift ontvangt waarmee zij ervan in kennis wordt gesteld dat zij een of meerdere illegaal verblijvende onderdanen van een derde land in België tewerkstelt, onthoudt deze onderneming zich ervan, met onmiddellijke ingang, de plaats van uitvoering van de Opdracht nog verder te betreden of nog verder uitvoering aan de Opdracht te geven, en wel tot de aanbestedende instantie een bevel in andere zin zou geven.

Hetzelfde geldt wanneer de voormelde Opdrachtnemer of onderaannemer ervan in kennis wordt gesteld:
ofwel door de Opdrachtnemer of de aanbestedende instantie, dat zij de in artikel 49/2, eerste dan wel tweede lid, van het Sociaal Strafwetboek bedoelde kennisgeving heeft ontvangen die betrekking heeft op deze onderneming;

ofwel door middel van de in artikel 35/12 van de wet van 12 april 1965 betreffende de bescherming van het loon der werknemers bedoelde aanplakking, dat zij een of meerdere illegaal verblijvende onderdanen van een derde land in België tewerkstelt.

De Opdrachtnemer of onderaannemer is er bovendien toe gehouden een clausule op te nemen in de onderaannemingsovereenkomst die zij desgevallend zou sluiten, op grond waarvan:

de onderaannemer er zich van onthoudt de plaats van uitvoering van de opdracht nog verder te betreden of nog verder uitvoering aan de opdracht te geven, indien uit een in uitvoering van artikel 49/2 van het Sociaal Strafwetboek opgestelde kennisgeving blijkt dat deze onderaannemer een illegaal verblijvende onderdaan van een derde land tewerkstelt;
de niet-naleving van de onder 1° gestelde verplichting aanzien wordt als een ernstige tekortkoming in hoofde van de onderaannemer, ingevolge waarvan de onderneming is gemachtigd de overeenkomst te verbreken;
de onderaannemer ertoe is gehouden een soortgelijke clausule als onder 1° en 2° op te nemen in de onderaannemingsovereenkomsten en ervoor te zorgen dat dergelijke clausules ook in de verdere onderaannemingsovereenkomsten worden opgenomen.

Loon verschuldigd aan werknemers

Wanneer de Opdrachtnemer of onderaannemer het in artikel 49/1, derde lid van het Sociaal Strafwetboek bedoelde afschrift ontvangt van kennisgeving waarmee hij ervan in kennis wordt gesteld dat hij een zwaarwichtige inbreuk heeft begaan op de verplichting zijn werknemers tijdig het loon te betalen waarop deze recht hebben, onthoudt hij zich ervan, met onmiddellijke ingang, de plaats van uitvoering van de Opdracht nog verder te betreden of nog verder uitvoering aan de Opdracht te geven, en wel tot hij het bewijs voorlegt aan de aanbestedende instantie dat de betrokken werknemers integraal zijn uitbetaald.

Hetzelfde geldt wanneer de voormelde opdrachtnemer of onderaannemer ervan in kennis wordt gesteld:
ofwel, naargelang het geval, door de opdrachtnemer of de aanbestedende instantie, dat hij de in artikel 49/1, eerste lid, van het Sociaal Strafwetboek bedoelde kennisgeving heeft ontvangen die betrekking heeft op deze opdrachtnemer of onderaannemer;

ofwel door middel van de in artikel 35/4 van de wet van 12 april 1965 betreffende de bescherming van het loon der werknemers bedoelde aanplakking.

De Opdrachtnemer of onderaannemer is er bovendien toe gehouden een clausule op te nemen in de onderaannemingsovereenkomst die hij desgevallend zou sluiten, op grond waarvan:

de onderaannemer er zich van onthoudt de plaats van uitvoering van de opdracht nog verder te betreden of nog verder uitvoering aan de opdracht te geven, indien uit een in uitvoering van artikel 49/1 van het Sociaal Strafwetboek opgestelde kennisgeving blijkt dat deze onderaannemer op zwaarwichtige wijze tekortschiet in zijn verplichting het aan zijn werknemers verschuldigde loon tijdig uit te betalen;

de niet-naleving van de onder 1° gestelde verplichting aanzien wordt als een ernstige tekortkoming in hoofde van de onderaannemer, ingevolge waarvan de opdrachtnemer is gemachtigd de overeenkomst te verbreken;
de onderaannemer ertoe is gehouden een soortgelijke clausule als onder 1° en 2° op te nemen in de onderaannemingsovereenkomsten en ervoor te zorgen dat dergelijke clausules ook in de verder onderaannemingsovereenkomsten worden opgenomen.

Non-discriminatie

De Opdrachtnemer verbindt zich ertoe bij het uitvoeren van deze opdracht niemand te discrimineren op grond van geslacht, leeftijd, seksuele geaardheid, burgerlijke staat, geboorte, vermogen, geloof of levensbeschouwing, politieke overtuiging, taal, gezondheidstoestand, handicap, fysieke of genetische eigenschappen, sociale positie, nationaliteit, zogenaamd ras, huidskleur, afkomst, nationale of etnische afstamming of syndicale overtuiging. Hij waarborgt dit zowel ten aanzien van zijn personeelsleden onderling als ten aanzien van derden, zoals deelnemers, bezoekers, externe medewerkers, enz.

De Opdrachtnemer verbindt zich ertoe, voor zo ver redelijk, aanpassingen door te voeren, op vraag van personen met een handicap, die de beperkende invloed van een onaangepaste omgeving op de participatie van een persoon met een handicap neutraliseren. (zie artikel 19 van het decreet van 10 juli 2008 houdende een kader voor het Vlaamse gelijke kansen- en gelijkebehandelingsbeleid).

De Opdrachtnemer verbindt zich ertoe de werknemers en derden zoals deelnemers, bezoekers, externe medewerkers, enz. mee te delen dat hij geen rekening zal houden met vragen of wensen van discriminerende aard.

Indien een personeelslid van de Opdrachtnemer zich tijdens de uitvoering van de Opdracht schuldig maakt aan discriminatie, pestgedrag, geweld of ongewenst seksueel gedrag, zal de Opdrachtnemer de nodige maatregelen treffen om een eind te maken aan dit gedrag en waar nodig het slachtoffer in eer herstellen. De werknemers met hiërarchische verantwoordelijkheden zullen toezien op het naleven van dit engagement.

Bij elke mogelijke klacht in dit verband tegen de Opdrachtnemer, zal deze zijn volledige medewerking verlenen aan eventueel onderzoek dat in dit verband verricht wordt door een meldpunt discriminatie of een andere organisatie, in dit verband aangesteld door de Vlaamse overheid.

De Opdrachtnemer vraagt tevens al zijn personeelsleden alert te zijn voor discriminatie, pestgedrag, geweld of ongewenst seksueel gedrag, in die zin dat ze de gevallen waar ze getuige van zijn, onmiddellijk dienen te melden aan een werknemer met hiërarchische verantwoordelijkheid.

De Opdrachtnemer verbindt zich ertoe om geen druk uit te oefenen op eigen personeelsleden, die slachtoffer worden van discriminatie, pestgedrag, geweld of ongewenst seksueel gedrag door een klant of een derde, om af te zien van eventuele indiening van een klacht of inleiding van een vordering voor de rechtbank in dit verband.

De Opdrachtnemer ziet erop toe dat ook de onderaannemers, die hij eventueel inschakelt voor de opdracht, zich houden aan deze uitvoeringsvoorwaarden.

Maatschappelijk verantwoord ondernemen

De Opdrachtnemer engageert zich dat hij en alle onderleveranciers, gedurende de volledige uitvoering van de opdracht, de 8 basisconventies van de IAO, en in het bijzonder:

het verbod op dwangarbeid (verdrag nr. 29 betreffende de gedwongen of verplichte arbeid, 1930 en verdrag nr. 105 betreffende de afschaffing van de gedwongen arbeid, 1957)
het recht op vakbondsvrijheid (verdrag nr. 87 betreffende de vrijheid tot het oprichten van vakverenigingen en bescherming van het vakverenigingsrecht, 1948)
het recht van organisatie en collectief overleg (verdrag nr. 98 betreffende het recht van organisatie en collectief overleg, 1949)
het verbod op discriminatie inzake tewerkstelling en verloning (verdrag nr. 100 betreffende de gelijke verloning, 1951 en verdrag nr. 111 betreffende discriminatie (beroep en beroepsuitoefening), 1958)
de minimumleeftijd voor kinderarbeid (verdrag nr. 138 betreffende de minimumleeftijd, 1973), alsook het verbod op de ergste vormen van kinderarbeid (verdrag nr. 182 over de ergste vormen van kinderarbeid, 1999) respecteren.

Voorwaarden Digipolis met betrekking tot het nieuwe sanctiepakket van de EU (Verordening 2022/576)

In verband met het nieuwe sanctiepakket van de EU (dat is vastgelegd in Verordening 2022/576) wil Digipolis benadrukken dat het haar op grond van voornoemde sancties verboden is opdrachten te verstrekken en/of te gunnen aan een Russische onderdaan/(rechts-)persoon (zoals hierna nader gespecificeerd). Kandidaat-inschrijvers moeten worden uitgesloten in het geval de opdracht wordt uitgevoerd door: 

Een Russische onderdaan of een in Rusland gevestigde natuurlijke persoon, rechtspersoon, entiteit of lichaam;  
Een rechtspersoon, entiteit of lichaam waarvan de eigendomsrechten voor meer dan 50% direct of indirect in handen zijn van een entiteit als bedoeld in punt a), of;  
Een natuurlijke persoon of rechtspersoon, entiteit of lichaam handelend namens of op aanwijzing van een entiteit als bedoeld punt a) of b);

Met inbegrip van onderaannemers, leveranciers of entiteiten wier capaciteit wordt ingeroepen in de zin van de richtlijnen inzake overheidsopdrachten, wanneer zij meer dan 10% van de waarde van de opdracht vertegenwoordigen. Door aan te melden voor c.q. in te schrijven op deze aanbesteding verklaart de kandidaat-inschrijver – voor het geval hij wordt uitgenodigd voor de gunningsfase – dat (i) de inschrijving niet strijdig is of zal zijn met Verordening 2022/576 en het daarin opgenomen sanctiepakket en (ii) dat de opdracht niet zal worden uitgevoerd in strijd met dat sanctiepakket. 

Facturatiemodaliteiten

Facturen worden voortaan enkel nog elektronisch toegelaten via Peppol. Kijk op de uitgebreide infopagina Factuur indienen voor uitleg en kies de manier die het beste bij je past:

via je facturatietool,
met Mercurius,
of vanuit je boekhoudpakket.

Zijn er redenen om de facturen toch nog via e-mail te bezorgen? Stuur deze dan naar factuur@antwerpen.be.
Gegevens, omschrijving en bijlagen van e-factuur:

Stap 1: Factureer aan de juiste entiteit:
- Entiteit: Digipolis AG
- KBO-nr: 0751541350
- Btw-nr: BE0751541350
Stap 2: Controleer of je zelf ook factureert vanuit de juiste entiteit.
Stap 3: Vermeld het bestelbonnummer in het correcte veld (bestelbonnummer, PO-nummer, ordernummer 4X13XXXXXX …).
Stap 4: Vermeld het juiste btw-tarief (of medecontractant, kleine onderneming vrijstelling o.b.v. art.44).
Stap 5: Vermeld je eigen btw- en IBAN-nummer.
Stap 6: Geef een duidelijke omschrijving van de opdracht en verwijs naar de juiste opdracht/offerteaanvraag door vermelding van A000XYZ/C00XYZ.
Stap 7: Controleer het factuurnummer.

Verzend geen factuur met eenzelfde factuurnummer. Peppol verwerkt dit als dubbele facturen en die worden niet aanvaard. Je kan optioneel en louter ter informatie een pdf toevoegen.

Voor aanmaningen en vragen over je factuur: AIF@digipolis.be
Prijsherzieningen zijn niet toegelaten.

Algemene niet-functionele vereisten

Digipolis heeft een set regels gedefinieerd waaraan alle IT-toepassingen in de nieuwe, veilige Antwerpse IT-omgeving moeten voldoen. Deze vereisten zijn dwingend voor nieuwe IT-toepassingen.

Bestaande IT-toepassingen die verder gebruikt worden moeten aan deze criteria worden aangepast. Deze ‘refactoring’ vraagt vaak een erg grote investering van tijd en geld.

Voor zover aan de orde voor de betrokken IT-toepassing, maakt refactoring geen deel uit van de Huidige Opdracht. Deze algemene niet-functionele vereisten worden hierna wel ter informatie meegedeeld. Ook al zijn ze niet relevant voor de beoordeling van de offerte of de uitvoering van de Opdracht, beroepen we ons op het professionalisme en de proactieve houding van de kandidaat-Opdrachtnemer om deze aspecten in het achterhoofd te houden bij de uitvoering van de Opdracht.

Data

Authentieke bronnen en hergebruik van data

Vereisten

We maken bij voorkeur gebruik van de extern beschikbare authentieke bronnen, die door bijvoorbeeld MAGDA ontsloten worden.

Indien de data niet extern beschikbaar is, maken we maximaal gebruik van de beschikbare authentieke bronnen die intern beschikbaar zijn om dubbele data te voorkomen: bijvoorbeeld de Adres-API of geodata in de centrale GIS-toepassing, enz.

Tot slot streven we naar optimaal hergebruik van data door gebruik te maken van lokale, unieke databronnen:

Shared Referentie Systemen: gedeeld binnen een functioneel domein;
Lokale Referentie Systemen: binnen de context van een specifieke IT-oplossing.

Deze vereisten gelden waar hergebruik van data juridisch toegelaten is. Het gebruik en hergebruik van persoonsgebonden data dient steeds afgetoetst te worden aan de geldende privacywetgeving.

Realtime data

Data uit IoT oplossingen, sensordata en andere realtime data, worden maximaal ingekoppeld op het Generiek IoT Platform van Digipolis. Het is aanbevolen om realtime datastromen te aligneren conform Smart Data Models (NGSI v2).

Datacatalogus

Indien in de offertevraag nieuwe databronnen gecreëerd worden, werkt de Opdrachtnemer mee om bij oplevering eenmalig de nodige inhoudelijke en technische metadata, herkomstinformatie en eventuele gebruiksbeperkingen te verzamelen, zodat deze toegevoegd kunnen worden aan de interne datacatalogus van Digipolis.

Volledige datalevenscyclus

We bekijken de volledige datalevenscyclus: herkomst, creatie, verzameling, verrijking, synthese, gebruik, deling, archivering, verwijdering, anonimisatie, migratie, … Het is belangrijk om deze ganse levenscyclus kwaliteitsvol, veilig, efficiënt, correct, transparant en conform de geldende wetgeving te maken.

De nodige maatregelen om data te archiveren, aantoonbaar te verwijderen na de bewaartermijn, te de-identificeren, worden voorzien.

Om dit inzichtelijk te maken dient de Opdrachtnemer een bijgewerkt dataflow diagram en datalevenscyclus-tabel aan te leveren. De eerste versies hiervan zijn meegeleverd bij deze offertevraag.

Bij het opmaken van de datalevenscyclus-tabel wordt dataclassificatie toegepast. We gebruiken deze classificatie voor het confidentialiteitsaspect van data: openbaar (verder afgekort als DC0), intern (DC1), vertrouwelijk (DC2) en geheim (DC3). Deze classificatie kan bepalend zijn om te bepalen welke vereisten naar bijv. security minimaal dienen gehanteerd te worden.

Open data

Naast wettelijke verplichtingen vanuit de federale regering en Europa om steeds meer data als open data te classificeren, hebben we binnen de groep stad Antwerpen de voorkeur om waar mogelijk hier verder in te gaan dan wat strikt verplicht is.

Voor data die door, in of over de stad gecapteerd worden, bekijken we standaard om deze als open data ter beschikking te stellen voor hergebruik. Tenzij er een beargumenteerde verklaring is om dit niet te doen. Kandidaat-opendatasets moeten worden ontsloten.

Het is eveneens aanbevolen om zoveel mogelijk gebruik te maken van andere beschikbare relevante open data.

Eigenaarschap

Antwerpen heeft steeds het ongelimiteerd en kosteloos eigenaarschap over de data die voor haar gecapteerd, opgeslagen en/of verwerkt wordt, en het recht om die in bredere context in te zetten en te ontsluiten. Dit recht is kosteloos, niet gelimiteerd in de tijd, volume en formaat. De Opdrachtnemer geeft in zijn offerte aan op welke manier de data kan worden ter beschikking gesteld en indien nodig overgedragen.

Dataminimalisatie

Om te zorgen dat data zo actueel – en juist – mogelijk is, efficiënt met data (opslag) omgegaan wordt, een overzicht behouden kan worden en maximaal kan worden voldaan aan wettelijke vereisten, werken we zoveel mogelijk met het principe van dataminimalisatie:

Data wordt slechts één keer verzameld en kopieën van data (dataduplicatie) worden vermeden.
De data wordt enkel opgehaald uit de bron wanneer ze nodig is.
Enkel de data die strikt noodzakelijk is voor het beoogde doel wordt ter beschikking gesteld van de benoemde afnemer.
De data wordt enkel opgeslagen indien noodzakelijk.
Data wordt niet langer bijgehouden dan functioneel nodig, of wettelijk bepaald is.
Indien kopieën van data toch nodig zijn, worden indien nodig updates van en naar de originele bron gestuurd en verwerkt, als deze updates kan verwerken.

(Inter-)nationale standaarden

Er wordt voorkeur gegeven aan (inter-)nationale standaarden en datamodellen en door gebruik te maken van standaarden van hogere overheden (zoals OSLO). Daar waar mogelijk worden enkel deze standaarden in het datalandschap gebruikt. Cartografische visualisaties.

De Stad gebruikt het ESRI GIS platform om services ter beschikking te stellen die datalagen en basemaps kan visualiseren. Oplossingen via Google Maps of OpenStreetMaps (OSM) worden vermeden. Dit garandeert een uniforme Look&Feel, en speelt een rol in de WCAG-compliancy (zie verder).

Rapportage

Onze BI-oplossing (Business Intelligence) dient via een ETL-principe de data uit de database van de applicatie te halen. Deze procedure zal door onze BI-oplossing getriggerd en gestart worden. Buiten documentatie tot het databaseschema en toegang tot de database, dient er niets in de applicatie te worden voorzien. Alternatieve toegangen tot de data is ook mogelijk: bijv. via een gedocumenteerde API.

De oplossing voorziet bij voorkeur in zijn eigen operationele rapportering. Voor gevallen waar dit niet mogelijk, is voorzien we vanuit Digipolis een oplossing tegen eind 2024.

Datakwaliteit

De oplossing creëert, gebruikt en behoudt gedurende de hele datalevenscyclus kwaliteitsvolle data die geschikt is voor het gewenste gebruik en voldoet aan de behoeften van de gegevensgebruikers. Zo houdt de oplossing indien mogelijk rekening: in de UI om foutieve invoer te vermijden, worden checks bij data import gedaan, worden validaties op velden gedaan (postcode correct, etc.), melding indien automatische imports niet lukken, …

Veiligheid, levenscyclus van applicaties en audit

Cryptografie

Kader

We wensen gebruik te maken van moderne en veilige versleutelingsmechanismes en up-to-date encryptiestandaarden.
Vereisten

Openbare, interne, vertrouwelijke en geheime data in transit moet geëncrypteerd worden op basis van de Mozilla standaard (v5.7).
Minimaal “Old” (dataclassificatie openbaar - DC0)
Minimaal “Intermediate” (dataclassificatie intern - DC1, vertrouwelijk - DC2)
Minimaal “Modern” (dataclassificatie geheim - DC3)
Data met classificatie DC1,DC2, DC3 in rust op servers, in applicaties en databanken moet daar eveneens geëncrypteerd (AES256) bewaard worden.

Vulnerability & Patch management

Kader

Op basis van een patch management procedure willen we er zeker van zijn dat alle operating systems, applicaties en firmware up-to-date blijft om veiligheidsredenen.

Vereisten

We maken een onderscheid op basis van de hosting locatie van de oplossing.

IaaS/SaaS/PaaS bij de Opdrachtnemer: Vulnerability en patch management verantwoordelijkheid ligt bij de Opdrachtnemer, die kan aantonen dat hij hiervoor gepaste procedures heeft uitgewerkt en toepast.
OnPrem bij Digipolis of IaaS cloud omgeving onder beheer van Digipolis:

Vulnerability en patch management verantwoordelijkheid ligt gezamenlijk bij Digipolis en de Opdrachtnemer.

Identiteit en Toegangsadministratie (IGA)

Kader

We houden controle over alle digitale identiteiten binnen de organisatie.

Vereisten

We maken een onderscheid tussen medewerker-identiteiten en burger-identiteiten. De oplossing kan één van deze identiteiten gebruiken, of een combinatie van beide.

Medewerker-identiteiten
De oplossing gebruikt Microsoft Entra-ID Digipolis tenant als IDP. Tenzij er een aantoonbare reden is waarom dit geen optie is waarna een risicobeheersbeslissing nodig is voor het beheer van deze alternatieve IDP. De accounts uit Entra-ID Digipolis tenant worden door een centrale werking beheerd, waardoor de oplossing altijd de meest kwalitatieve accounts gebruikt.

De oplossing hanteert OIDC als authenticatie protocol. Een secundaire optie is SAML. Als laatste alternatief is een protocol hanteren dat rechtstreeks met ActiveDirectory OnPremise (e.g. Kerberos) authentiseert, maar dit gaat gepaard met een risico-beslissing.

Indien de oplossing nood heeft aan User objecten in de eigen oplossing kan een Integratie / User-provisioning opgezet worden met Microsoft Entra-ID Digipolis, hetzij omdat dit out-of-box beschikbaar is, hetzij omdat dit specifiek ontwikkeld kan worden via binnen deze offertevraag.

Burger-identiteiten
De oplossing gebruikt altijd de Aprofiel realm beschikbaar op een centrale Keycloak. Hiervoor bestaat er een gedocumenteerde specificatie om een specifieke OIDC manier te volgen.

Je kan ook hierbij ook een authenticatie niveau (low, substantial, high) meegeven zodat één of meerdere aanmeldmethodes aan de gebruikers ter beschikken wordt gesteld, zoals bijvoorbeeld itsMe.

Identiteit en Toegangsbeheer (IAM)

Kader

We wensen centrale controle over toegangen en op het toegangsbeheer van alle software oplossingen.

Vereisten

We maken een onderscheid tussen medewerker-identiteiten en burger-identiteiten. De oplossing kan één van deze soort identiteiten gebruiken of een combinatie van beide.

Medewerker-identiteiten

De oplossing hanteert Microsoft Entra-ID Digipolis tenant als Authz-provider tenzij er een aantoonbare reden is waarom dit geen optie is waarna een risicobeheersbeslissing nodig is voor het beheer van deze alternatieve Authz-provider. Deze autorisaties zijn omkaderd met centrale beheersprocessen, waardoor zij steeds de meest kwalitatieve autorisaties zijn.

De oplossing hanteert één van de volgende manieren om automatisch toegekende of ingetrokken autorisaties te ontvangen:

Via claims in het authenticatie protocol (OIDC of SAML). Er is een voorkeur om met app-roles te werken tenzij het aantoonbaar is dat er moet gewerkt worden met security groepen.
Er is een User-Provisioning actief vanuit Microsoft Entra-ID Digipolis tenant waarbij de autorisatie(s) voor een User wordt meegegeven.
Er wordt een autorisatie-matrix (RBAC) vormgegeven die de volgende dimensies bevat en duidelijk gedocumenteerd wordt:
- Welke permissies hebben at-runtime welke toegelaten functionaliteit(en) in de oplossing?
- Welke permissies geven welke CRUD-toegang tot welke geclassificeerde (2,3) databron?
- Welke applicatierollen bevatten welke permissies?
- Wie moet welke applicatierollen goedkeuren en met welke frequentie (her)goedkeuren?
- Wat zijn eventuele extra vragen waarvan de antwoorden noodzakelijk zijn voor de goedkeurder?

Alle “Elevated Access” autorisaties binnen de oplossing (bijvoorbeeld een beheerder) worden benoemd en zijn voorwerp van extra autorisatie beheer zoals: dienen er extra partijen de toekenning van deze rol goed te keuren en met welke (eventueel kortere) frequentie?

Burger-identiteiten

Er worden géén expliciete rechten toegekend naast diegene die toegang geven tot publieke data of tot een dataset waar de burger toegang toe heeft (bijvoorbeeld een aangevraagd rijbewijs)

Asset- en configuratiebeheer

Kader

Asset en configuratie beheer heeft als hoofddoel om van alle configuratie-items in de organisatie een overzicht te hebben. Hierbij worden alle elementen die gekoppeld zijn aan een bepaald product en haar relaties in kaart gebracht, om zo een volledig overzicht te behouden.

Vereisten

In geval van SaaS, PaaS, IaaS aangeboden door de Opdrachtnemer wordt er verwacht dat de Opdrachtnemer aan asset- en configuratiemanagement doet en dit up-to-date houdt. Details en service-afspraken worden opgenomen in een serviceovereenkomst.
Als de ontwikkeling en hosting gebeurt binnen de omgevingen van Digipolis, dan wordt dit aspect opgenomen door Digipolis.

Organisatie, Risico en Compliance (ORC/GRC)

Kader

GRC verwijst naar de strategie en structuur die een organisatie veilig houdt, in overeenstemming met de gemaakte afspraken.

Vereisten

In geval van SaaS, PaaS, IaaS aangeboden door de Opdrachtnemer wordt er verwacht dat de Opdrachtnemer hier intern een processen en een bepaalde werking voor heeft. Hij kan dit ook aantonen vóór de go-live.
Als de ontwikkeling gebeurt binnen de omgevingen van Digipolis, dan wordt dit aspect opgenomen door Digipolis.

Veiligheid van de ontwikkelingslevencyclus

Kader

Black box: SaaS oplossing waarin we een bewijs vragen van de SDLC-werking van de Opdrachtnemer (zie vereisten)
White box: op maat gemaakte oplossing binnen een ontwikkelomgeving binnen Digipolis, die onderstaande vereisten afdwingt

Vereisten

Voor dataclassificaties DC1, DC2 en DC3 gelden volgende vereisten binnen de ontwikkelingslevencyclus:

Static Application Security Testing;
Dynamic Application Security Testing;
Sourcecode analysis;
Secret detection;
Software Bill Of Materials.

Netwerkveiligheid

Kader

Een veilige netwerkomgeving creëren voor apparaten, toepassingen, gebruikers en applicaties.

Vereisten

Netwerksegmentatie is noodzakelijk om de attack surface van assets te verkleinen en de impact van aanvallen in te perken. Hiervoor zullen Diagrammen van de netwerkarchitectuur beschikbaar moeten zijn teneinde interne kennis omtrent de setup te waarborgen.
Toegang tot niet-publieke assets van de Groep Stad Antwerpen (en dus ook toegang vanop afstand) moet verlopen via het daarvoor dienende Leveranciersportaal van Digipolis. Hier kan, via een VPN-toepassing, toegangen voorzien naar interne bronnen die vanop afstand bereikt moeten worden in het kader van het bouwen, uitbaten of ondersteunen van de oplossing.
Ontsluiten van een toepassing kan bereikt worden via verschillende scenario’s waarbij een scenario wordt gekozen en opgezet samen met de netwerkarchitecten van Digipolis.

Operationele veiligheid

Kader

Dit gaat met name over de clausule en het proces om klanten te informeren over security incidenten. De werking van de het Security Operations Center (SOC): logging, monitoring en opvolging.
Het SOC van Digipolis zorgt voor een monitoring van security gerelateerde incidenten bij applicaties en infrastructuur binnen het netwerk.

Vereisten

In geval van SaaS, PaaS, IaaS uitgebaat door de Opdrachtnemer wordt er verwacht dat de Opdrachtnemer hier intern een oplossing voor biedt. Vanuit Digipolis verwachten we een clausule en proces om klanten (in dit geval Digipolis) te informeren over security incidenten.
Als de ontwikkeling gebeurt binnen de omgevingen van Digipolis, dan wordt dit aspect afgedekt door Digipolis.

Waarneembaarheid

Kader

Aan de hand van de juiste logging wensen we een goede monitoring op te houden.

Vereisten

Volgende soorten logging worden gedefinieerd en verwacht om bijgehouden te worden, afhankelijk van de classificatie van de verwerkte data:
1. Technische/systeemlogging (DC1, DC2 en DC3)
2. Applicatielogging (DC1, DC2 en DC3)
3. Persoonsgegevenslogging (DC2 en DC3)
De retentieperiode is evenredig met de classificatie van de verwerkte data en proportioneel. Voor persoonsgegevenslogging dient steeds de wettelijke context en –vereisten voor logging gevolgd te worden.
De toegankelijkheid van de logs moet gewaarborgd worden voor bestaande monitoring- en verwerkingstools en de logs moeten ontsloten worden voor de aangeduide stakeholders.

Gegevensbescherming door ontwerp (GDPR)

Vereisten

Standaardinstellingen moeten altijd de maximale gegevensbescherming voor de betrokkenen aanbieden.
Elke verwerking van persoonsgegevens moet voldoen aan een aantal criteria om als een wettige verwerking te kunnen worden aangemerkt. Het project pakt de minimum verplichte zaken op die hierbij nodig zijn, zoals het opstellen van de GDPR-checklist en de checklist risico, het aanmaken en administreren van de verwerking in het verwerkingsregister, het opstellen en afhandelen van een verwerkingsovereenkomst, het opstellen van een privacyverklaring, het inregelen van toestemmingvraag en het voorzien in een DPIA.
In je project zal je bij het ontwerp rekening houden met de vereisten die de verwerking met zich meebrengen zoals rechtmatigheid, doelbinding, doorgifte, retentie en archivering, passende beveiliging enz. De vereisten en de maatregelen worden door het project gedocumenteerd en geëvalueerd. Overblijvend risico's worden benoemd en na advies vanuit de DPO van een risicobeheer beslissing voorzien.
De te betrekken stakeholders zijn:
1. Voor de projecten van de stad Antwerpen: projectteam, GDPR-aanspreekpunten van de stad en DPO-office stad;
2. Voor Digipolis projecten: projectteam en DPO Digipolis;
3. Voor projecten van de overige entiteiten (AGVESPA, MPA, AGSO, ATLAS, PZA, BZA, ZBA enz.): projectteam en DPO van de entiteit.
De passende beveiligingsmaatregelen zijn afhankelijk (‘passend’) van de doelstelling en de middelen die bij elke verwerking van persoonsgegevens moeten worden vastgelegd. Doel en middelen van een nieuwe verwerking worden tijdens de intakefase van een verwerking bepaald, in samenwerking tussen project, security-team, betrokken DPO(‘s) en Opdrachtnemer. De bijhorende passende maatregelen worden door het project gedefinieerd, opgenomen in het project en door het project gedocumenteerd.
De analyse rond gegevensbescherming wordt vanuit het project geïnitieerd en ondersteund. De vereisten worden vervolgens meegenomen in het ontwerp van de oplossing en als project deliverables benoemd. Er wordt opvolging voorzien van de oplevering via het proces van kwaliteitscontroles op verschillende momenten in het project.
Het hele proces van privacy by design is iteratief. Dat betekent dat bevindingen of voortschrijdende inzichten en scope aanpassingen tijdens de levensduur van het project mogelijke nieuwe of veranderende vereisten meebrengen op het vlak van gegevensbescherming.

Integratie en ontwikkeling

Automatische deploys en infrastructuur als code

Vereisten

We verwachten dat oplossingen maximaal integreren met de Application Lifecycle Management-omgeving (CI/CD) die wordt voorzien door Digipolis indien de hosting gebeurt door Digipolis

Huisstijl en merkarchitectuur van de stad Antwerpen en het wettelijk kader met betrekking tot toegankelijkheid

Kader

Onze digitale producten voldoen qua uitzicht en gebruikerservaring aan de afspraken binnen de groep Antwerpen, de huisstijl en de Digitale Merkarchitectuur. Voor Digipolis gebouwde applicaties voldoen aan de technische afspraken met betrekking tot het front-end gebruikersgedeelte. We volgen de Europese richtlijn met betrekking tot webtoegankelijkheid (WCAG) voor alle applicaties van de groep stad Antwerpen.

Er zijn veel digitale initiatieven binnen de groep stad Antwerpen, maar voor de gebruiker moet elke digitale oplossing zowel vormelijk als functioneel deel uit maken van het geheel.

De Stad Antwerpen streeft via e-inclusie naar een hoge toegankelijkheid voor alle burgers. WCAG helpt daarbij, omdat de Europese standaard bepaalt hoe webinformatie meer toegankelijk kan gemaakt worden voor mensen met een beperking.

Vereisten

Omwille van toegankelijkheid (WCAG) en e-inclusiviteit moeten web toepassingen correct functioneren in veelgebruikte browsers en operating systems.
Je past de domeinen, huisstijl, profielen en metanavigatie correct toe in de gevallen waar dat vereist is
De communicatieverantwoordelijken zijn aanspreekpunt voor validatie van de huisstijl in wireframes, designs en het opgeleverde product.
Voorziene React componenten worden optimaal gebruikt bij front-end ontwikkeling
Oplossingen voldoen aan de Web Content Accessibility Guidelines (WCAG) 2.1 niveau AA, zodat alle digitale content toegankelijk en helder is
Het projectteam moet de toegankelijkheid van de digitale oplossing laten valideren door een onafhankelijke partij die hiervoor IAAP gecertificeerd is. Hiervoor zal het projectteam beroep kunnen doen op het raamcontract van de stad (dit kan aangevraagd worden via toegankelijkheid@antwerpen.be) of kan het projectteam zelf een audit bestellen bij een gecertificeerde Web Accessibility Specialist. Resultaten worden in samenspraak met de stadsklant besproken en waar nodig geremedieerd of opgenomen in de toegankelijkheidsverklaring
Elke toepassing moet voorzien zijn van een toegankelijkheidsverklaring waarin wordt opgelijst in welke mate ze aan WCAG voldoet en welke maatregelen er worden genomen om volledig toegankelijk te zijn.

Tabel - Correct gebruik van huisstijl en merkarchitectuur van de stad Antwerpen en het wettelijk kader met betrekking tot toegankelijkheid

Tabel - Te ondersteunen besturingssystemen en browsers

Digipolis technische biotoop

Kader

Qua technologiekeuzes heeft Digipolis een agile technische biotoop. Het gaat zowel over front-end technologieën als back-end technologieën. Het staat partners vrij om onze technische keuzes uit te dagen, zolang we samen een oplossing kunnen vinden voor het onderhoud van de oplossing.

Vereisten

Alle oplossingen voldoen bij voorkeur aan de gekozen technische standaarden van Digipolis. Als dat niet zo is dan gaan we ervan uit dat het om een managed service gaat. In dat geval zijn volledige support afspraken extra belangrijk. Met bijzondere aandacht voor het onderhoud, patching en lifecycle management van de infrastructuurelelementen en niet-conforme technische onderdelen.
We maken binnen onze technische biotoop een onderscheid tussen: verplicht (moet gebruikt worden indien van toepassing), ondersteund (er is brede vraag naar deze technologie, maar we denken dat er betere alternatieven zijn) en geprefereerd (volgens ons de beste oplossing binnen onze technische biotoop)
De technologiekeuzes moeten getoetst worden aan onderstaande criteria:
1. Excelling user-centric UX: de keuze voor eigentijdse UX front-end technologie.
2. Open community ready: de creatie van een kader (SDK, API’s, open data, open source, …) waardoor ook externe gemeenschappen mee kunnen ontwikkelen.
3. Embracing DevOps: het streven naar een optimale samenwerking tussen alle partijen zodat we in steeds kortere cycli meer tastbare resultaten in gebruik nemen. Ons einddoel: ‘continuous deployment of shippable products with zero-downtime’. Future proof: nu anticiperen op de evidente technologische ontwikkelingen van morgen (open & smart government, digital workplace, omnichannel citizen engagement, open data, open services, edge analytics, digital government platforms, internet of everything, web-scale IT, hybrid cloud and IT).
4. Highly scalable: flexibel en zonder kost kunnen opschalen en afslanken van IT-omgevingen in functie van de behoeften van het moment.

Integratiepatronen en interfaces van services

Vereisten

Services, clients en servers verbinden op netwerkniveau niet rechtstreeks met elkaar (poort tot poort). Dat betekent dat er altijd een tussenliggende partij (de Hub of ADC - Application Delivery Controller) op protocolniveau is, die veilige communicatie afdwingt.
Data en business capabilities worden ontsloten via een API-interface (RESTful, OData of Graph) en indien deze intern of in opdracht ontwikkeld worden, wordt sterk aanbevolen om deze conform de Digipolis API Design Guidelines te designen en te documenteren.
API's van bestaande producten of services dienen kwalitatief te worden aangeleverd, voorzien van de nodige documentatie voor hun gebruik.
Events moeten ontwikkeld worden conform de Event design & style requirements, voor events met vertrouwelijke inhoud (o.a. alle persoonsgegevens) voorzie je passende beveiliging of - indien dat niet mogelijk is - zogenaamde “light events” (meldingsbericht, gevolgd door een API-call). Bestaande webhooks in producten worden geval per geval bekeken en geëvalueerd.
Integratie tussen de services beantwoorden aan de volgende richtlijnen:
1. van interne (dit is zowel het on-premise netwerk als de Digipolis beheerde Azure omgeving) consumer naar interne service via interne API Gateway is verplicht;
2. van externe consumer naar interne service via perimeter API Gateway is verplicht;
3. van interne consumer naar externe service er is geen verplichting om over API Gateway te gaan;
4. van externe service naar externe service er is geen verplichting om over API Gateway te gaan.

Testen van applicaties

Vereisten

Zowel unit- als integratietesten met goede test coverage zijn verplicht en worden door de ontwikkelaar uitgevoerd. Je integreert hiervoor maximaal met ons test raamwerk.
Met gedocumenteerde API testen worden de in de OpenAPI documentatie (Swagger) beschreven services getest.
Performantietesten zijn zowel load testen als het gradueel opdrijven van het aantal gebruikers om de impact te testen. Deze testen kunnen zowel tijdens de ontwikkelfase als tijdens de acceptatiefase uitgevoerd worden. De uitgevoerde performantietesten tonen aan dat de verwachte piek en continue belasting kan gedragen worden door de applicatie.
End-to-end gebruikerstesten kunnen manueel worden uitgevoerd, repetitieve en regressietesten worden geautomatiseerd.

Productdocumentatie

Vereisten

Er wordt een productsite opgemaakt én onderhouden in SharePoint met daarin de minimale informatie zoals bepaald in het voorbeeldsjabloon.
Er wordt een infrastructuur (technische) en conceptuele landschapstekening opgemaakt van het product en haar koppelingen, vlak voor de MTP en dan verder aangevuld na de MTP volgens de in Digipolis vastgelegde standaard. Deze tekening wordt verder onderhouden indien er zich wijzigingen voordoen. Deze tekening wordt ondergebracht in een afzonderlijke (veilige) Sharepoint locatie.
Het product en haar koppelingen worden opgenomen in de software inventaris (CMDB), de software inventaris wordt up-to-date gehouden.
API's worden gedocumenteerd op onze API-marktplaats.

Relatie tot derde partijen, ondersteuning en service/operations-by-design

Ondersteuningsafspraken

Verplicht invullen van ons service en onderhoud sjabloon: zie bijlage "04. voorbeeldsjabloon onderhoud".

Vereisten

Een volledige beschrijving van de geleverde dienstverlening, de verantwoordelijkheden van de verschillende partijen, reactie- en beschikbaarheidstijden, wijze van meten en rapporteren rond gemaakte afspraken (SLA's), contactgegevens en communicatiekanalen, releasebeheer en beschikbaarheid
Duidelijke afspraken met betrekking tot patch management en software updates. Dringende veiligheidspatches moeten bovendien binnen de 48 uur kunnen worden uitgevoerd. Periodiek worden veiligheidsupdates uitgevoerd.
Het product en al haar onderdelen maakt altijd gebruik van de lange-termijn ondersteunde versie van raamwerken, bibliotheken, componenten, programmeertaal, etc. De nodige afspraken worden gemaakt om ervoor te zorgen dat dit actief wordt opgevolgd en gerealiseerd.

Monitoring

Vereisten

Afhankelijk van de plaats waar het product gehost en beheerd wordt, zal de Opdrachtnemer:
zijn eigen monitoring tool en dashboard ter beschikking stellen van de ondersteunende diensten van Digipolis (technisch dashboard) en van de partner (functioneel dashboard).
De monitoring opzetten in de Digipolis monitoring tool en een technisch en functioneel dashboard aanmaken en ter beschikking stellen van de ondersteunende teams en de partner(s).

Het dashboard geeft een duidelijk zicht op de status van de verschillende componenten van het product over de ganse looptijd van het contract (uptime, downtime…). Uit de monitoring en het dashboard moet eenvoudig op te maken zijn welke component voor een onderbreking in de dienstverlening zorgt, wat de uptime/downtime van de verschillende componenten en het volledige product is over een zelf in te stellen tijdsspanne is.

Rapporteren

Vereisten

De Opdrachtnemer rapporteert periodiek (standaard is dat maandelijks) over de afgesproken service-level agreements (SLAs). In deze rapportering komt minimaal onderstaande aan bod:

de afgesproken SLAs met hun resultaten voor de afgelopen maand;
de compensatie voor de niet-gehaalde SLAs;
de acties die ondernomen worden om de dienstverlening te verbeteren bij laag scorende SLAs en niet-gehaalde SLAs;
de Opdrachtnemer zorgt ervoor dat de resultaten grafisch voorgesteld worden en duidelijk weergeven wat de status is van de verschillende SLAs;
de Opdrachtnemer zorgt ervoor dat de rapportering van de SLAs enkel betrekking heeft op Digipolis en het product waar de SLA betrekking op heeft. Statistieken die de globale werking van een product over alle klanten heen weergeeft, is onvoldoende.