Je eerste zakelijke klant stuurt een beveiligingsvragenlijst

Je hebt een product, er is een klant, en dan komt er een bestand met veertig vragen over zaken waar je nog nooit over hebt nagedacht. Dat is geen pesterij: sinds de Cyberbeveiligingswet moeten organisaties de risico's in hun keten kunnen onderbouwen, en jij bent die keten. Hieronder hoe je zo'n lijst aanpakt zonder te doen alsof je een groot bedrijf bent.

Terug naar OneDayBuild

Waarom je die lijst krijgt

Niet omdat ze je wantrouwen, maar omdat ze het moeten kunnen laten zien.

Sinds de Cyberbeveiligingswet dit jaar in werking trad, hebben duizenden Nederlandse organisaties een zorgplicht die uitdrukkelijk ook de risico's in hun toeleveringsketen omvat. Praktisch betekent dat: als jouw product bij hen draait of bij hun gegevens kan, moeten zij kunnen onderbouwen dat ze daarover hebben nagedacht.

Die verplichting rolt naar beneden. Een groot bedrijf krijgt vragen van zijn toezichthouder, stelt ze door aan zijn leveranciers, en die stellen ze door aan de partijen die zij inhuren. Ergens aan het eind van die ketting zit een oprichter met een product dat vier maanden bestaat en een bestand met veertig vragen.

Het is dus geen oordeel over jouw product. Het is iemand die een vakje moet kunnen aankruisen. Dat is goed nieuws, want het betekent dat een eerlijk en compleet antwoord vaak beter werkt dan een indrukwekkend antwoord.

Welke vragen je wel en niet kunt beantwoorden

De lijst is bijna altijd geschreven voor een groter bedrijf. Dat mag je zeggen.

Hier hoor je een antwoord op te hebben
  • Waar staan de gegevens en wie kan erbij?
  • Hoe zijn gegevens versleuteld, onderweg en in opslag?
  • Hoe log je in en wordt tweestapsverificatie gebruikt?
  • Wat log je, en hoe lang bewaar je dat?
  • Wat gebeurt er als er iets misgaat: wie belt wie, en binnen hoeveel tijd?
  • Welke onderaannemers gebruik je, zoals hosting, mail en betaalverkeer?
Hier mag je nee op zeggen
  • Bent u ISO 27001 gecertificeerd? Vrijwel geen enkel jong product is dat, en het antwoord is nee.
  • Heeft u een aparte beveiligingsafdeling en een jaarlijkse penetratietest?
  • Heeft u een uitgeschreven bedrijfscontinuïteitsplan met een uitwijklocatie?
  • Voert u achtergrondonderzoek uit bij indiensttreding van personeel?

Vier dingen die je in een week regelt

Dit is het minimum waarmee je zo'n lijst geloofwaardig invult.

Weten wat je draait

Een lijst met de diensten die je gebruikt en de componenten in je code, met per stuk waarvoor je ze gebruikt. Die lijst is het antwoord op minstens vijf vragen tegelijk, en zonder die lijst gok je bij elke vraag over onderaannemers. Zie wat zit er in je app.

Registratie inbouwen

Inloggen, rechtenwijzigingen en fouten vastleggen, met een bewaartermijn die je kunt noemen. Bijna elke vragenlijst vraagt hiernaar, en het is het enige antwoord dat je niet kunt improviseren omdat het er is of niet.

Toegang op orde

Tweestapsverificatie op je eigen accounts, aparte sleutels per toepassing, en geen wachtwoorden in je code. Dit is werk van een middag en het is de categorie waar een klant het snelst achter komt als je liegt.

Eén pagina beleid

Geen handboek, maar één pagina waarop staat hoe je met updates, toegang, back-ups en incidenten omgaat. Dat je het klein houdt is geen probleem; dat het er niet is wel.

Hoe je invult wat je nog niet hebt

Het antwoord dat het beste werkt is zelden ja, en nooit een leeg vakje.

Zet bij alles wat je niet hebt geen nee maar nee met een datum: nog niet, dit staat gepland voor dat kwartaal, en zo lossen we het risico nu op. Dat laatste stukje is waar het om gaat. Een klant wil weten of het risico is afgedekt, niet of jij een certificaat hebt. Draai je bijvoorbeeld geen jaarlijkse penetratietest, dan is het antwoord dat je afhankelijkheden automatisch gemonitord worden en dat je binnen een bepaalde termijn patcht. Dat is een echt antwoord.

Waar je niet mee wegkomt is ja invullen omdat het beter oogt. Als de klant later merkt dat een antwoord niet klopt, is dat een contractueel probleem en geen ongemakkelijk gesprek. En de kans dat het opvalt is groter dan je denkt, want dit soort lijsten komt terug in de bijlage van je overeenkomst.

Vraag ook gerust terug welke vragen echt van toepassing zijn. Veel lijsten zijn geschreven voor leveranciers die op locatie komen of die zelf datacenters draaien, en de contactpersoon weet vaak zelf ook dat de helft niet past. Dat gesprek is doorgaans korter en nuttiger dan veertig vakjes invullen.

En zorg dat je het antwoord op de incidentvraag echt kunt geven. Wie belt wie, binnen hoeveel tijd, en waar staat dat. Hoe je dat aan je eigen kant inricht staat in er is iets misgegaan: wat zeg je tegen je gebruikers en in wat log je en hoe lang.

Veelgestelde vragen

Waarom krijg ik als klein bedrijf zo'n vragenlijst?

Omdat de Cyberbeveiligingswet organisaties verplicht om ook de risico's in hun toeleveringsketen te onderbouwen. Die verplichting rolt door: een groot bedrijf krijgt vragen van zijn toezichthouder en stelt ze door aan zijn leveranciers. Het is geen oordeel over jouw product maar een vakje dat iemand moet kunnen aankruisen.

Wat als ik de meeste vragen met nee moet beantwoorden?

Dat is normaal en zelden een probleem. Vul geen kaal nee in maar nee met een datum en met hoe je het risico nu afdekt. Een klant wil weten of het risico beheerst is, niet of je een certificaat hebt. Draai je geen jaarlijkse penetratietest, dan is het antwoord dat je afhankelijkheden gemonitord worden en dat je binnen een bepaalde termijn patcht.

Mag ik ja invullen als ik het bijna geregeld heb?

Nee. Deze lijsten belanden vaak als bijlage bij je overeenkomst, waarmee een onjuist antwoord een contractueel probleem wordt in plaats van een ongemakkelijk gesprek. Bijna geregeld is een prima antwoord als je het opschrijft; het is alleen geen ja.

Welke vragen moet ik echt kunnen beantwoorden?

Zes: waar staan de gegevens en wie kan erbij, hoe is versleuteld, hoe wordt ingelogd, wat log je en hoe lang, wat gebeurt er bij een incident, en welke onderaannemers gebruik je. Dat zijn de vragen die over jouw product gaan en niet over de omvang van je organisatie.

Moet ik ISO 27001 halen om zaken te kunnen doen?

Meestal niet. Certificering is een organisatiebrede investering die zelden past bij een product van een paar maanden oud, en de meeste klanten weten dat. Wat ze wel willen is dat je de onderliggende vragen kunt beantwoorden. In aanbestedingen kan het wel een harde eis zijn, en dan is het een ander gesprek.

Wat regel ik als eerste?

Een overzicht van welke diensten en componenten je gebruikt, en registratie van inloggen en rechtenwijzigingen. Die twee samen beantwoorden een groot deel van de lijst, en het zijn precies de antwoorden die je niet kunt improviseren omdat ze er zijn of niet.

Kan ik terugvragen welke vragen van toepassing zijn?

Ja, en dat is vaak het slimste wat je doet. Veel lijsten zijn geschreven voor leveranciers die op locatie komen of eigen datacenters draaien, en je contactpersoon weet meestal zelf ook dat de helft niet past. Dat gesprek duurt korter en levert meer op dan veertig vakjes invullen.

Wat is het risico als ik dit negeer?

Dat je de klant niet krijgt, en steeds vaker ook dat je bij een bestaande klant bij een audit uit de boot valt. Dit soort vragen wordt de komende jaren normaal in plaats van uitzonderlijk, dus de tijd die je er nu in steekt hoef je maar één keer te maken.

Liever een werkend prototype dan een tool-keuze?

Stuur ons je idee. Wij kijken in een intake mee welke flow je wilt testen en leveren in één werkdag een klikbaar prototype, met de juiste tools voor jouw geval.