Naar de inhoud

ISO 27001-checklist voor IT- en softwarebedrijven

5 min leestijd Laatst gecontroleerd op

Deze ISO 27001-checklist ordent het werk voor een IT- of softwarebedrijf in vijf fasen: fundament, risico's, invoeren, toetsen en certificeren. Elk punt verwijst naar een clausule van de versie uit 2022 of naar een Annex A-maatregel. Hij vervangt geen risicobeoordeling: welke maatregelen je invoert, volgt uit je eigen risico's.

Deze checklist verdeelt een ISO 27001-traject voor een IT- of softwarebedrijf in vijf fasen, met achter elk punt de clausule of Annex A-maatregel uit de versie van 2022 waar het bij hoort. De clausules 4 tot en met 10 zijn verplicht. De Annex A-punten zijn voorbeelden die bij softwarebedrijven vaak uit de risicobeoordeling komen, geen vaste lijst.

De nummers verwijzen naar de norm; de omschrijvingen zijn in eigen woorden. Houd de norm zelf erbij als je een punt afvinkt.

Fase 1: fundament

  1. Context vastgelegd. Interne en externe onderwerpen die je beveiliging raken, zoals afhankelijkheid van één hostingpartij of groei naar de zorgmarkt. Ga ook na of klimaatverandering relevant is. (4.1)
  2. Belanghebbenden en hun eisen. Klanten, verwerkersovereenkomsten, toezichthouders, certificeringseisen van klanten. (4.2)
  3. Scope vastgesteld. Welke diensten, systemen, teams en locaties, en wat bewust buiten de scope valt, met de raakvlakken naar buiten. (4.3)
  4. Directie aan boord. Een directielid dat eigenaar is en tijd en budget vrijmaakt. (5.1)
  5. Informatiebeveiligingsbeleid vastgesteld. Kort, door de directie ondertekend en bekendgemaakt. (5.2)
  6. Rollen belegd. ISMS-eigenaar, risico-eigenaren, wie incidenten afhandelt. (5.3, A 5.2)

Fase 2: risico's en keuzes

  1. Methode voor risicobeoordeling. Hoe je kans en impact inschat en wanneer een risico acceptabel is. (6.1.2)
  2. Risico's beoordeeld. In bedrijfstaal, met een eigenaar per risico. Denk aan klantdata in productie, een gelekte API-sleutel, uitval van de cloudregio, een kwetsbare dependency. (6.1.2, 8.2)
  3. Risicobehandelplan. Per risico: verminderen, vermijden, overdragen of accepteren, met akkoord van de risico-eigenaar. (6.1.3, 8.3)
  4. Verklaring van Toepasselijkheid. Alle 93 Annex A-maatregelen langs, met per maatregel toepassen of uitsluiten, de reden en de status. (6.1.3)
  5. Doelstellingen. Een paar meetbare doelen, bijvoorbeeld "kritieke kwetsbaarheden binnen een vastgestelde termijn opgelost". (6.2)
  6. Wijzigingen gepland. Hoe je veranderingen in het ISMS zelf plant, zoals een nieuwe vestiging of een tweede product in de scope. (6.3)

Fase 3: invoeren

Mensen en organisatie

  1. Competenties en training. Securitytraining bij onboarding en periodiek, aantoonbaar gevolgd. (7.2, 7.3, A 6.3)
  2. Screening en geheimhouding. Afspraken bij indiensttreding en uitdiensttreding. (A 6.1, 6.2, 6.5, 6.6)
  3. Documentbeheer. Versies, eigenaar, vaststelling en een vaste plek. (7.5)
  4. Communicatie. Wie wat meldt aan wie, intern en richting klanten. (7.4)

Leveranciers en cloud

  1. Leveranciersoverzicht. Hosting, subverwerkers, SaaS-tools, met beoordeling en afspraken in contracten. (A 5.19 tot en met 5.22)
  2. Clouddiensten. Hoe je clouddiensten kiest, inricht, bewaakt en verlaat. (A 5.23)

Toegang

  1. Toegangsbeleid en toegangsreviews. Wie mag waar bij, met periodieke controle en snelle intrekking bij vertrek. (A 5.15 tot en met 5.18)
  2. Beheerdersrechten en authenticatie. Minimale beheerrechten en sterke authenticatie op productie en broncode. (A 8.2, 8.5)

Ontwikkeling en beheer

  1. Veilig ontwikkelen. Beveiligingseisen, code reviews, veilig programmeren en testen in de ontwikkelstraat. (A 8.25 tot en met 8.29)
  2. Scheiding van omgevingen en wijzigingsbeheer. Ontwikkel, test en productie gescheiden, wijzigingen via een vast proces, geen echte klantdata in test zonder maatregelen. (A 8.31 tot en met 8.33)
  3. Kwetsbaarheden en configuratie. Dependencies en systemen bijgewerkt, configuraties vastgelegd. (A 8.8, 8.9)
  4. Logging en monitoring. Wat je logt, hoe lang, en wie ernaar kijkt. (A 8.15, 8.16)
  5. Back-ups. Gemaakt, versleuteld waar nodig en periodiek teruggezet als test. (A 8.13)
  6. Endpoints en thuiswerken. Laptops beheerd en versleuteld, afspraken over werken op afstand. (A 8.1, 6.7)

Incidenten en continuïteit

  1. Incidentproces. Melden, beoordelen, reageren, leren en bewijs bewaren, inclusief meldplichten richting klanten en toezichthouders. (A 5.24 tot en met 5.28, 6.8)
  2. Continuïteit. Hoe je platform en dienstverlening doorlopen bij uitval, en of dat getest is. (A 5.29, 5.30)
  3. Wet- en regelgeving. Overzicht van wettelijke en contractuele eisen, waaronder de AVG. (A 5.31, 5.34)

Fase 4: toetsen

  1. Meten. Wat je meet om te weten of het ISMS werkt, en wie de uitkomst bekijkt. (9.1)
  2. Interne audit. Een programma dat in de loop van de tijd het hele ISMS raakt, uitgevoerd door iemand die zijn eigen werk niet toetst. (9.2)
  3. Directiebeoordeling. Vaste onderwerpen, vastgelegde besluiten en acties. (9.3)
  4. Afwijkingen opgevolgd. Oorzaak, correctie en controle of het heeft gewerkt. (10.2)

Fase 5: certificeren en bijhouden

  1. Certificerende instelling gekozen. Geaccrediteerd voor ISO/IEC 27001, offerte vergeleken over de hele cyclus.
  2. Fase 1-audit voorbereid. Scope, beleid, risicobeoordeling, Verklaring van Toepasselijkheid, interne audit en directiebeoordeling liggen klaar.
  3. Fase 2-audit voorbereid. Bewijs per maatregel vindbaar, de juiste mensen beschikbaar voor gesprekken.
  4. Jaarlijkse cyclus gepland. Risico's herzien, interne audit, directiebeoordeling en verbetering, vóór elke surveillance-audit. (10.1)

Hoe je de checklist gebruikt

Werk de fasen op volgorde af, maar verwacht dat je teruggaat. Een interne audit in fase 4 levert bijna altijd punten op die je in fase 3 moet bijstellen, en dat is precies wat een auditor wil zien. Vink een punt pas af als er bewijs is: een vastgesteld document, een ingevuld register of een uitgevoerde test met datum.

Uitleg over de norm staat in het artikel over ISO 27001, het verloop van de audit in het artikel over certificering.

Veelgestelde vragen

Wat moet er minimaal op een ISO 27001-checklist staan?

Alle clausules 4 tot en met 10, want die zijn verplicht, plus de Annex A-maatregelen die uit je risicobeoordeling volgen. Een checklist die alleen Annex A afloopt, mist het managementsysteem eromheen.

Welke Annex A-maatregelen zijn het belangrijkst voor een softwarebedrijf?

Meestal toegangsbeheer, leveranciers en clouddiensten, veilig ontwikkelen, kwetsbaarhedenbeheer, logging, back-ups en incidentbeheer. Welke voor jou zwaar wegen, bepaalt je risicobeoordeling.

Kan ik een checklist gebruiken als Verklaring van Toepasselijkheid?

Nee. De Verklaring van Toepasselijkheid legt per Annex A-maatregel vast of je hem toepast, waarom, en of hij is ingevoerd. Een checklist helpt je daar te komen, maar is geen vervanging.

Hoe lang duurt het om de checklist af te werken?

Dat hangt af van je uitgangssituatie en scope. Voor een softwarebedrijf van 10 tot 100 medewerkers is een half jaar tot een jaar tot aan de certificeringsaudit een gangbare ervaring, zonder garantie.

Lees ook

Bronnen

  1. ISO, ISO/IEC 27001:2022 Information security management systems
  2. ISO, ISO/IEC 27002:2022 Information security controls
  3. NEN, veelgestelde vragen over ISO/IEC 27001
  4. IAS, tekst ISO/IEC 17021-1:2015 sectie 9 (fase 1 en fase 2)

Trustbird wordt gebouwd met twee gecertificeerde design partners, en we zoeken meer bedrijven die zich bij hen aansluiten tegen co-founderprijs.

Word design partner