ISO-proof software ontwikkelen.

De auditor belt. Is je software voorbereid?

Je hebt een ISO 27001-certificering. Of je klant eist er een. Of je zit midden in het traject en merkt dat je software op bepaalde punten niet voldoet aan wat de auditor verwacht. Dat is het moment waarop bedrijven bij ons aankloppen.

Niet omdat hun software slecht is, maar omdat die nooit is gebouwd met compliance in het achterhoofd. En dat merk je. Geen audit trail, geen versleuteling van gevoelige data, geen rol-gebaseerde toegang die daadwerkelijk afdwingt wie wat mag zien. De techniek staat los van het beleid — en dat is precies wat een auditor opmerkt.

Wij bouwen software die daar wél op is ingericht. Niet door achteraf een compliance-laag eroverheen te plakken, maar door het vanaf het begin mee te nemen in architectuur, development en deployment.

Wat is ISO 27001 en waarom raakt het je software?

ISO 27001 is de internationale standaard voor informatiebeveiliging. Het gaat niet om een checklist afvinken — het is een managementsysteem dat beschrijft hoe je organisatie omgaat met informatierisico's. Van beleid en procedures tot technische maatregelen.

De standaard zelf zegt niet hoe je je software moet bouwen. Maar Annex A — de lijst met beheersmaatregelen — raakt je software op tientallen punten. Toegangscontrole, cryptografie, logging, incidentbeheer, leveranciersbeheer, change management. Als je software daar niet op is ingericht, wordt het lastig om aan te tonen dat je organisatie voldoet.

En dat is het punt: ISO 27001 gaat over aantoonbaarheid. Niet "we doen ons best met security", maar "we kunnen bewijzen dat we het goed geregeld hebben". Je software is daarin een cruciaal bewijsstuk.

ISO 27001 vraagt niet om perfecte software. Het vraagt om aantoonbare beheersing. Dat begint bij architectuurkeuzes, niet bij documenten.

Waar software meestal tekortschiet

De meeste applicaties die wij tegenkomen bij bedrijven in een ISO-traject hebben dezelfde problemen. Het zijn geen grote beveiligingslekken — het is het ontbreken van structuur die een auditor nodig heeft om te verifiëren.

Geen audit trail

Wie heeft wanneer wat gewijzigd? Bij de meeste applicaties is dat niet te achterhalen. Een auditor wil kunnen zien dat mutaties traceerbaar zijn. Niet alleen voor troubleshooting, maar als bewijs dat je toegangscontrole werkt en dat je wijzigingen kunt reconstrueren.

Toegang is te breed

Iedereen is admin. Of er zijn wel rollen, maar die worden niet consequent afgedwongen. Het principle of least privilege — een kernprincipe van ISO 27001 — wordt in de praktijk zelden goed doorgevoerd. Gebruikers hebben toegang tot data die ze niet nodig hebben voor hun werk.

Geen versleuteling van data at rest

Persoonsgegevens, financiële data, medische informatie — het staat onversleuteld in de database. Voor de applicatie maakt het niet uit, maar voor een auditor is het een rode vlag. Annex A vereist cryptografische maatregelen waar dat passend is.

Logging is afwezig of incompleet

Geen login-logging, geen registratie van mislukte authenticatiepogingen, geen monitoring van wie welke data opvraagt. Als er een incident plaatsvindt, kun je niet reconstrueren wat er is gebeurd.

Change management ontbreekt

Code gaat rechtstreeks naar productie zonder review, zonder test, zonder vastlegging. Een auditor verwacht een gecontroleerd change-proces met goedkeuring, testing en traceerbaarheid.

Hoe wij ISO-proof software bouwen

ISO-proof software is geen apart product. Het is de manier waarop we bouwen. Dit zijn de concrete maatregelen die wij standaard implementeren voor klanten met compliance-eisen:

Role-Based Access Control (RBAC)

Elke gebruiker krijgt precies de rechten die nodig zijn — niet meer. Rollen en permissies zijn configureerbaar zonder code-aanpassingen. Wie welke data mag zien, bewerken of verwijderen is vastgelegd en afdwingbaar. Bij elke API-call en elke pagina wordt gecontroleerd of de gebruiker geautoriseerd is.

Volledige audit trail

Elke mutatie wordt gelogd: wie, wat, wanneer, welke waarden veranderden. Audit logs zijn onwijzigbaar — ze kunnen niet worden aangepast of verwijderd door gebruikers. Dit geeft je auditor precies het bewijs dat toegangscontrole en data-integriteit geborgd zijn.

Versleuteling op meerdere lagen

Data in transit is versleuteld via TLS. Gevoelige velden in de database worden versleuteld opgeslagen met Laravel's ingebouwde encryptie. Backups worden versleuteld bewaard. Sleutelbeheer is gescheiden van de applicatie — keys staan niet in de codebase.

Security headers en hardening

Content Security Policy, Strict-Transport-Security, X-Frame-Options, X-Content-Type-Options — de complete set security headers die browsers vertellen hoe ze je applicatie veilig moeten behandelen. Geen debug-informatie in productie, geen directory listings, geen verbose error messages.

Authenticatie en sessiebeveiliging

Twee-factor authenticatie, brute-force bescherming, sessie-invalidatie bij wachtwoordwijziging, wachtwoordcontrole tegen bekende datalekken via Have I Been Pwned. Sessies verlopen automatisch na inactiviteit. Alles configureerbaar per omgeving.

Monitoring en alerting

Mislukte loginpogingen, ongeautoriseerde toegangspogingen, ongewone patronen — het wordt gelogd en gedetecteerd. Niet pas als een auditor ernaar vraagt, maar real-time. Zodat je kunt ingrijpen voordat het een incident wordt.

Security is geen feature die je aan het einde toevoegt. Het is een architectuurkeuze die je aan het begin maakt — en die bij elke sprint wordt meegenomen.

Ons stappenplan: van intake tot ISO-proof platform

Elk project met compliance-eisen doorloopt bij ons een vast traject. Geen overkill aan documentatie, maar de juiste stappen op het juiste moment.

Stap 1 — Verkenning en scope

We beginnen met begrijpen welke eisen er gelden. ISO 27001? NEN 7510? Eisen vanuit je klant of sector? We brengen samen in kaart welke Annex A-maatregelen relevant zijn voor jouw software en welke risico's prioriteit hebben.

Stap 2 — Architectuur met compliance als fundament

Op basis van de scope ontwerpen we de technische architectuur. Toegangsmodel, dataclassificatie, versleutelingsstrategie, logging-architectuur — het wordt vastgelegd vóórdat we gaan bouwen. Dit document dient later ook als bewijsmateriaal voor je auditor.

Stap 3 — Iteratief bouwen met security-checks

We bouwen in korte iteraties, net als bij elk project. Maar elke sprint bevat een security-review. Code reviews checken niet alleen functionaliteit maar ook: is de autorisatie correct? Wordt input gevalideerd? Worden gevoelige data correct afgeschermd? Automated tooling scant op kwetsbaarheden in dependencies.

Stap 4 — Gecontroleerd change management

Elke wijziging doorloopt ons CI/CD-proces: code review, automatische tests, staging-omgeving, goedkeuring en dan pas productie. Alles traceerbaar via Git-history en deployment logs. Dit is direct het bewijs voor je change management-beleid.

Stap 5 — Pentest en validatie

Voordat de applicatie live gaat, wordt een professionele penetratietest uitgevoerd door een onafhankelijke partij. Bevindingen worden opgelost en hertest. Het pentest-rapport is onderdeel van je compliance-dossier.

Stap 6 — Oplevering met documentatie

Je ontvangt niet alleen werkende software, maar ook de technische documentatie die je auditor nodig heeft: architectuurdocument, dataflow-diagrammen, overzicht van beveiligingsmaatregelen, en deployment-procedures. Geen stapel onleesbare documenten, maar gerichte documentatie die aansluit op wat een auditor vraagt.

Stap 7 — Doorlopend beheer en monitoring

Na oplevering monitoren we de applicatie continu. Security patches worden direct doorgevoerd. Dependencies worden bijgehouden. Periodieke her-tests valideren dat de applicatie compliant blijft. ISO 27001 is geen eenmalig stempel — het is een doorlopend proces, en je software moet daarin mee.

Voor welke sectoren is dit relevant?

ISO 27001 is sector-onafhankelijk, maar in de praktijk zien we het vaakst bij:

• Financiële dienstverlening — Verzekeraars, accountants en fintech-partijen die met gevoelige financiële data werken en compliance moeten aantonen aan toezichthouders en klanten.
• Zorg — Organisaties die met medische gegevens werken en naast ISO 27001 vaak ook NEN 7510 moeten implementeren.
• SaaS-bedrijven — Elk serieus SaaS-platform krijgt vroeg of laat de vraag van enterprise-klanten: "Zijn jullie ISO 27001-gecertificeerd?" Zonder certificering mis je deals.
• Overheid en semi-overheid — Gemeenten, uitvoeringsinstanties en samenwerkingsverbanden die wettelijk verplicht zijn om informatiebeveiliging aantoonbaar te hebben ingericht.
• B2B-platformen — Bedrijven die data van hun klanten verwerken en contractueel moeten aantonen dat die data veilig is.

ISO 27001 vs. "wij nemen security serieus"

Elke softwareleverancier zegt dat security belangrijk is. Dat is ook zo. Maar er is een wereld van verschil tussen "we hashen wachtwoorden en gebruiken HTTPS" en "we kunnen aantonen dat onze software voldoet aan de eisen van Annex A van ISO 27001".

Het eerste is het minimum. Het tweede is wat enterprise-klanten verwachten, wat auditors controleren en wat je organisatie nodig heeft om serieus genomen te worden in sectoren waar informatiebeveiliging niet optioneel is.

Wij bouwen het tweede. Niet omdat het ingewikkeld moet zijn, maar omdat het de juiste manier is om software te bouwen voor organisaties die met gevoelige data werken.

Mijn kijk hierop

ISO-proof software bouwen is geen raketwetenschap. Het is discipline. Het is bij elke feature even stilstaan bij de vraag: kan ik dit verantwoorden tegenover een auditor? Wordt de toegang gecontroleerd? Is de wijziging traceerbaar? Wordt de data beschermd?

Wat ik te vaak zie is dat bedrijven eerst software laten bouwen en daarna pas ontdekken dat het niet past binnen hun compliance-kader. Dan wordt het een dure refactoring. Beter is om het vanaf het begin goed te doen. Dat kost niet significant meer — het vereist alleen de juiste kennis en de discipline om het consequent door te voeren.

Als je in een ISO-traject zit of compliance-eisen hebt vanuit je klanten, laten we praten. Niet over theorie, maar over hoe we jouw software concreet inrichten zodat je auditor tevreden is en je klanten vertrouwen hebben.