Waar beveiligingsteams ISO 27001 op uitvoeren, volgens een r/grc-thread

Een beveiligingsprofessional met een ISO 27001 Lead Implementer-certificaat stelde op r/grc een eenvoudige vraag: ze implementeren een ISMS bij een bedrijf van ongeveer 1.000 medewerkers dat niet cloud-afhankelijk is, en ze willen weten of Confluence plus Jira het op lange termijn kunnen dragen, of dat ze een gespecialiseerd GRC-platform nodig hebben.

ISMS Copilot wordt in deze thread nooit genoemd. Dat is precies waarom het een van de meest nuttige stukken marktonderzoek is die we de afgelopen maanden hebben gelezen. Verschillende bijdragers onthulden hun eigen zakelijke belangen, maar niemand sprak namens ons. Dit is wat de praktijkmensen zeiden en wat we eruit hebben meegenomen.

Atlassian en spreadsheets zijn normaal, en ze certificeren

Het hoogst gewaardeerde antwoord, van een praktijkdeskundige die een ISMS beheert voor 2.000 mensen en werkt met SOC 2, ISO 27001, SOX en PCI, was duidelijk: de meeste ISMS’en zijn gebouwd op Atlassian, spreadsheets, koffie en doorzettingsvermogen. Een consultant met meer dan 100 implementaties achter zich wierp tegen dat een goed passend hulpmiddel het leven op schaal aanzienlijk makkelijker maakt. Beide hebben gelijk, en de thread is eerlijk over waar de grens ligt.

Bij ongeveer duizend mensen meldden verschillende praktijkdeskundigen dezelfde spanning in de Atlassian-en-spreadsheet-aanpak: de koppelingen. Risico’s, controles, activa, eigenaren en bewijs overschrijven elkaar wanneer ze in Jira-issues leven. Een map met bewijs vertelt je niet of een record is geaccepteerd, afgewezen of nog actueel is. De Verklaring van Toepasselijkheid en de gedateerde versies blijven alleen audit-klaar door handmatig werk. Anderen in de thread reageerden fel op spreadsheets op deze schaal en pleitten voor een gespecialiseerd platform, dus lees dit als een levend debat, niet als een vonnis.

Dat is een echt probleem, en het antwoord dat de GRC-markt verkoopt, is om alles naar een platform te verplaatsen.

De GRC SaaS-vermoeidheid is reëel

Een ander thema kwam meer dan eens naar voren: de meeste GRC-tools worden beschreven als taaktrackers met bewijs dat er als een aanhangsel aan is vastgeklonken. Een bijdrager, die momenteel compliance beheert voor een organisatie met 2.000 medewerkers, vergeleek de prijs van een Vanta-licentie met die van een junior medewerker en koos voor de junior. De tools die in de ruimte worden gerespecteerd, automatiseren ofwel controle-testen of lezen een document uit tegen de vereiste. Configuratie-afhankelijke platforms laten, in de woorden van één bijdrager, de data slechter achter dan Excel.

Lees dit als een koper die spreekt: de waarde zit in de oordeelslaag, het deel dat zegt of het beleid de controle dekt, of de rechtvaardiging in de VvT de toets doorstaat, of het register en de VvT overeenkomen. Het bijhouden wie de actie-eigenaar is, is een opgelost probleem, in Jira of waar dan ook.

De nieuwe speler is AI, en het bezwaar is aansprakelijkheid

Het meest interessante deel van de thread is wat mensen suggereerden in plaats van nog een platform te kopen: gebruik Claude. Een bijdrager onthulde hun eigen product gebouwd op dat idee, een agent die de VvT en het risicoregister scaffold. Een ander beschreef het zelf bouwen van GRC-tools met een LLM, terwijl ze het register deterministisch en buiten het model hielden.

De tegenreactie was direct en correct: het is allemaal leuk en aardig tot de resultaten hallucineren en je persoonlijk aansprakelijk bent. Dezelfde persoon antwoordde dat de oplossing ligt in zorgvuldig ontwerp, bewijs verzamelen met citaten en beveiligingen, en het deterministische archief buiten het model houden.

Die uitwisseling is de hele stelling van ons product in één commentaarthread, geschreven door kopers zonder ons in de kamer.

Wat we eruit hebben meegenomen

De thread deelt compliance-werk op in twee lagen. Het register, de tickets, het bewijsspoor: die leven in het hulpmiddel dat de organisatie al vertrouwt, of dat nu Jira, Confluence, een spreadsheet of een GRC-platform is. De oordeelsbeslissingen – of een rechtvaardiging in de VvT voldoet aan clausule 6.1.3 d), of een beleid dekt A.5.15, waar de VvT en het risicoregister niet overeenkomen – zijn raamwerkvragen, en dat zijn precies de vragen die een specialist moet beantwoorden.

Dit is hoe dat werkt met ISMS Copilot, concreet. Je AI, de Claude, Cursor of ChatGPT waar je al mee werkt, leest de pagina of de ticket als je die tools al hebt gegeven, en stuurt ons een korte uittreksel. ISMS Copilot antwoordt met de clausule, de vereiste of de concepttekst, en markeert wat niet bevestigd kon worden, zodat je de bron kunt controleren. Je ondertekent elke regel, en het bestand blijft in je wiki, je tracker of je spreadsheet. We koppelen niet aan Jira of Confluence, slaan je register niet op en schrijven niets terug.

Dat is waarom we er bewust niet het platform zijn waar deze thread naar zocht. De oorspronkelijke vraagsteller heeft een beslissing nodig over waar het register moet leven, en verschillende bijdragers zeiden dat ze het waar het is kunnen houden. Wat ze vervolgens nodig hebben – en wat elke bijdrager die AI noemde op zijn eigen manier zei – is de oordeelslaag met citaten, op aanvraag, naast de bestanden die al bestaan.

De eerlijke grenzen

Twee dingen waar de thread om vraagt die wij niet doen, met opzet. We lossen geen integriteit van het register op: als risico’s en controles elkaar overschrijven in Jira, is dat een Jira-probleem, en het verplaatsen naar een tracker die beter past is een legitiem antwoord. En we automatiseren geen controle-testen, want een onbevestigd testresultaat is precies het hallucinerende bewijs waar de thread bang voor is.

Een AI-antwoord is een concept waarvoor jij aansprakelijk bent. De taak van het product is om dat concept traceerbaar te maken naar de standaard, elke niet-bevestigde regel te markeren en je in staat te stellen met open ogen te ondertekenen. Dat is dezelfde afspraak die de zorgvuldige bouwers in de thread beschreven, zonder iemand te vragen hun ISMS te verplaatsen om het te doen.