Kennisbank · Aanbestedingsdocumenten

Wat staat er echt in een ICT-aanbesteding van een gemeente?

Bijgewerkt 6 augustus 2026 · 8 min lezen

Wat een gemeentelijke ICT-aanbesteding bevat: de eisen- en wensenlijst, beveiliging, toegankelijkheid, de inkoopvoorwaarden en waar je op afvalt.

Een gemeentelijke ICT-aanbesteding bestaat uit een aanbestedingsleidraad met de spelregels, een programma van eisen en wensen (meestal een spreadsheet met honderden regels), een concept-overeenkomst met de inkoopvoorwaarden, een prijzenblad en een reeks bijlagen over beveiliging, koppelvlakken en verwerking van persoonsgegevens. Anders dan bij fysieke diensten valt de beslissing hier zelden op je plan van aanpak. Hij valt op twee plekken: op die eisenlijst, waar één "nee" op een harde eis genoeg is om af te vallen, en op de concept-overeenkomst, waar aansprakelijkheid, beveiliging en exit worden geregeld. Daar begin je dus, en niet bij het schrijven.

Waar de eisen van een gemeente vandaan komen

Veel eisen in een gemeentelijke ICT-aanbesteding zijn geen wens van deze inkoper maar beleid waar de gemeente zelf aan gebonden is. Dat is nuttig om te weten: zulke eisen zijn zelden onderhandelbaar, en je kunt ze aan zien komen voordat het document open is.

Kom je een van deze onderwerpen niet tegen in de stukken terwijl het wel om verwerking van gegevens van inwoners gaat, dan is dat eerder een omissie dan een versoepeling. Reken erop dat het alsnog terugkomt in de nota van inlichtingen of bij de verificatie.

De eisen- en wensenlijst: hier val je af

Het programma van eisen en wensen is bij ICT vaak een spreadsheet waarin je per regel invult of je eraan voldoet, soms met een toelichting van een beperkt aantal tekens. Drie dingen gaan daar mis.

Het verschil tussen eis en wens wordt over het hoofd gezien. Een eis is een knock-out: antwoord je "nee", of laat je een regel leeg, dan ben je ongeldig. Een wens levert punten op. Sorteer de lijst als eerste op dit onderscheid en tel hoeveel harde eisen er zijn. Hoe je een knock-out herkent, staat in het artikel over knock-outcriteria herkennen.

"Voldoet met een workaround" bestaat niet. Als de lijst alleen ja of nee toelaat, is een ja die je later moet nuanceren risicovol: bij de verificatie of bij een demo moet je het waarmaken. Twijfel je of jouw oplossing onder de eis valt, vraag dan om verduidelijking in de vragenronde in plaats van het antwoord op te rekken.

Toekomstige functionaliteit telt niet. Eisen gaan in beginsel over wat je op het moment van inschrijven kunt leveren. Staat er iets op je roadmap, dan is dat pas bruikbaar als de aanbesteding expliciet ruimte laat voor levering op een latere datum.

Ga er niet vanuit dat de eisenlijst intern consistent is. Bij grote lijsten spreken regels elkaar tegen, of staat er een eis in die uit een oud document is overgenomen. Dat is geen reden om zelf een interpretatie te kiezen: stel de vraag, want het antwoord in de nota van inlichtingen gaat boven de oorspronkelijke tekst en geldt voor iedereen.

Geschiktheidseisen bij ICT

• Financiële draagkracht: een omzeteis of een verklaring over de financiële positie. De Aanbestedingswet 2012 begrenst hoe hoog een omzeteis mag zijn in verhouding tot de geraamde opdrachtwaarde, en de Gids Proportionaliteit gaat er zelfs van uit dat een omzeteis in beginsel niet nodig is. Vind je hem onredelijk, kaart het dan aan tijdens de vragenronde.
• Technische bekwaamheid: referentieopdrachten die vergelijkbaar zijn in aard en omvang. ICT is een dienst of een levering, en daarvoor mag een aanbestedende dienst in beginsel vragen naar opdrachten uit de afgelopen drie jaar. Let op de eis dat een referentie bij een overheidsorganisatie is uitgevoerd, want die sluit veel MKB-leveranciers uit terwijl hij niet altijd te rechtvaardigen is.
• Certificering: ISO 27001 komt het vaakst voor, in het zorgdomein aangevuld met NEN 7510. Vraag je af of het certificaat als eis of als bewijsmiddel is opgenomen: soms volstaat het aantonen van gelijkwaardige maatregelen, en dat scheelt een certificeringstraject.

Gunningscriteria: demo, casus en totale kosten

ICT-opdrachten worden vrijwel altijd gegund op beste prijs-kwaliteitverhouding. De weging verschilt per aanbesteding en is niet wettelijk vastgelegd. Wat je in deze sector vaker tegenkomt dan elders:

• Een demo of scripted demonstratie. Je krijgt een scenario dat je live moet uitvoeren, beoordeeld door een team. Het draaiboek staat meestal in een bijlage. Neem het serieus, want een demo weegt vaak zwaarder dan het geschreven deel en je kunt hem niet herstellen.
• Een praktijkcasus of proof of concept. Een uitgewerkte opgave waarop je een oplossing beschrijft, soms met een technische uitwerking.
• Interviews met sleutelfunctionarissen. Beoordeeld wordt de persoon die het werk gaat doen, niet je bedrijf. Zet daar dus niet je beste verkoper neer.
• Totale kosten over de looptijd. Het prijzenblad rekent zelden met alleen een licentieprijs. Verwacht implementatie, beheer, ondersteuning, meerwerktarieven en soms een fictief afnamevolume waarmee de scores worden berekend. Reken zelf na wat dat volume met je marge doet als het niet wordt afgenomen.

Voordat je uren in kwaliteit steekt: kijk naar de rekenmethode. Bij een relatieve prijsformule hangt je prijsscore af van de anderen, en dat verandert je strategie. Hoe dat werkt, staat in het artikel over relatieve beoordeling en je prijsstrategie.

De concept-overeenkomst: waar de echte risico's zitten

Bij ICT is dit geen formaliteit. Loop in elk geval deze punten na:

• De inkoopvoorwaarden. Gemeenten leggen vaak de GIBIT op, het Rijk de eigen IT-voorwaarden. Ze zijn opgesteld vanuit de opdrachtgever, en afwijken mag meestal niet. Lees ze daarom als onderdeel van je kostprijs, niet als juridische bijlage.
• Service levels. Beschikbaarheidspercentages, reactie- en hersteltijden, en de vraag of daar boetes of servicekredieten aan hangen. Toets of je die tijden waar kunt maken buiten kantooruren.
• Aansprakelijkheid. Is die beperkt tot een bedrag of een percentage van de contractwaarde, en zijn er uitzonderingen waarvoor geen beperking geldt. Leg dat naast je verzekeringspolis voordat je inschrijft.
• Intellectueel eigendom. Wie krijgt de rechten op maatwerk, en mag de gemeente resultaten hergebruiken of openbaar maken. Voor gemeenten is opensourcepublicatie van maatwerk een reëel uitgangspunt geworden.
• Exit en dataportabiliteit. Welke medewerking moet je verlenen aan een opvolger, in welk formaat lever je data op, en mag je daarvoor kosten rekenen. Staat daar niets over, dan is dat je eigen risico.
• Verwerkersovereenkomst. Locatie van de opslag, inschakelen van subverwerkers, meldplicht bij incidenten en het recht op audits.

Is een van deze punten voor jouw bedrijf onwerkbaar, dan is de vragenronde het moment. Van inschrijvers wordt verwacht dat ze bezwaren tegen de voorwaarden vóór de sluiting kenbaar maken. Wie zonder klagen inschrijft en pas na de gunning bezwaar maakt, vangt daar in de regel bot.

Raamovereenkomst, dynamisch aankoopsysteem of gewone opdracht

Bij ICT loopt lang niet alles via een klassieke opdracht.

• Raamovereenkomst. Vaak met meerdere leveranciers, waarbij per opdracht een minicompetitie volgt. Winnen betekent hier alleen dat je mee mag doen, niet dat er omzet is. Zoek op of er een afnamegarantie is (meestal niet) en hoeveel partijen worden gecontracteerd. In de klassieke sector geldt bovendien een maximale looptijd van vier jaar voor een raamovereenkomst, behoudens uitzonderingen.
• Dynamisch aankoopsysteem. Veel gebruikt voor inhuur van ICT-personeel. Anders dan bij een raamovereenkomst kun je gedurende de hele looptijd alsnog toetreden, en dat maakt het een van de toegankelijkste routes voor kleinere partijen.
• Losse opdracht. Eenmalige implementatie of aanschaf, met beheer voor een vaste periode.

Welke procedurevormen er zijn en wat ze voor je inschrijving betekenen, staat in het artikel over openbare, niet-openbare en onderhandse procedures.

Veelgestelde vragen

Wat is de GIBIT?

De gemeentelijke inkoopvoorwaarden bij IT: een standaardset contractvoorwaarden die veel gemeenten hanteren bij IT-opdrachten, met bijbehorende kwaliteitseisen. Ze worden vrijwel altijd onverkort van toepassing verklaard. Er bestaan meerdere versies, dus controleer welke versie in jouw aanbesteding wordt genoemd.

Moet ik ISO 27001 hebben om mee te kunnen doen?

Niet altijd. Soms is het een harde eis, soms is het een van de manieren om aan te tonen dat je aan de beveiligingseisen voldoet. Staat er "of gelijkwaardig", dan mag je met een onderbouwing van je maatregelen komen. Lees de exacte formulering, want het verschil kan een certificeringstraject schelen.

Wat betekent WCAG 2.1 niveau AA voor mijn oplossing?

Dat je software toegankelijk moet zijn voor mensen met een beperking, volgens een vastgelegde set succescriteria. Voor overheidswebsites en apps volgt die eis uit het Tijdelijk besluit digitale toegankelijkheid overheid. Verwacht dat je erop wordt getoetst en dat de gemeente om onderbouwing vraagt, bijvoorbeeld een toegankelijkheidsonderzoek.

Mag ik voorbehouden maken bij de concept-overeenkomst?

Meestal niet. Een voorbehoud op de contractvoorwaarden wordt vaak aangemerkt als een voorwaardelijke inschrijving en leidt dan tot ongeldigheid. De route is een vraag stellen in de vragenronde, niet een aantekening bij je inschrijving.

Hoeveel tijd kost een ICT-aanbesteding aan de kant van de inschrijver?

Dat verschilt sterk met de omvang van de eisenlijst en of er een demo bij hoort. Reken erop dat de eisenlijst en de demo samen meer tijd kosten dan het schrijfwerk. Wat inschrijven in het algemeen kost, staat in het artikel over de kosten van inschrijven op een aanbesteding.

Waar het op neerkomt

Lees een gemeentelijke ICT-aanbesteding in deze volgorde: eerst de harde eisen in de eisenlijst, dan de beveiligings- en toegankelijkheidsbijlagen, dan de concept-overeenkomst met de inkoopvoorwaarden, en pas daarna de gunningscriteria en het prijzenblad. In die volgorde weet je snel of je überhaupt geldig kunt inschrijven, en dat is bij ICT een reëlere vraag dan of je een mooi verhaal kunt schrijven. Alles wat onduidelijk blijft, gaat als vraag de vragenronde in, want na sluiting is het te laat.

← Alle artikelen