DAM auditlogs: risico's en aandachtspunten

Auditlogs worden meestal pas interessant als het misgaat. Iemand verwijdert per ongeluk een campagnefoto, een externe partij downloadt beelden waar geen licentie voor is, of een auditor vraagt wie wanneer welk bestand heeft goedgekeurd.

Dan blijkt opeens dat je DAM wel zegt dat-ie alles logt, maar dat je de data niet terugvindt, niet kunt exporteren, of simpelweg niet bewaart voor de wettelijke termijn. Ik heb genoeg implementaties gezien waar het auditlog achteraf een natte vingerwerk bleek. Niet omdat de software het niet kon, maar omdat niemand er bij de inrichting over had nagedacht. En dat terwijl een goede audit-trail gewoon het verschil is tussen een soepele audit en een stevige reprimande.

Waarom auditlogs in een DAM geen bijzaak zijn

Een Digital Asset Management-systeem is de centrale bron van waarheid voor al je media. Van ruwe RAW-bestanden tot goedgekeurde merkuitingen.

Alles wat erin gebeurt – uploaden, downloaden, bewerken, verwijderen, delen – zou gelogd moeten worden. Niet omdat het leuk is, maar omdat het bewijs levert. Bewijs dat je licenties correct beheert, dat je AVG-proof werkt, dat je geen ongeautoriseerde toegang hebt gehad.

Wat me telkens opvalt: bedrijven kopen een dure DAM-licentie, maar vergeten de logging-configuratie.

Ze vertrouwen op standaardinstellingen. En standaardinstellingen bewaren logs vaak maar 30 dagen, of loggen alleen wie inlogt, niet wat diegene daarna doet. Dat is vragen om problemen.

Risico 1: Onvoldoende bewaartermijn van logs

Veel DAM-oplossingen – zeker de bekende enterprise-systemen – hebben een default retention van 30 tot 90 dagen.

Voor een eenmalige interne check is dat genoeg. Maar voor compliance met ISO 27001, AVG of sectorregelgeving heb je vaak minimaal één jaar nodig, soms langer. Als je dat niet instelt, ben je bij een audit simpelweg bewijsloos. Eerlijk gezegd zie ik dat vooral bij organisaties die hun DAM zelf hebben ingericht zonder begeleiding van een specialist.

De loginstellingen staan ergens diep in een configuratiescherm en niemand kijkt ernaar om. Tot de accountant vraagt om een overzicht van alle bestandsdownloads in 2023 – en je alleen de laatste maand hebt.

Neem een oplossing als Beeldbank.nl. Die biedt standaard al langere bewaartermijnen en duidelijke exportmogelijkheden.

Maar ook daar geldt: check altijd zelf wat de daadwerkelijke retention is en pas hem aan op jouw eisen. Reken niet op wat er in de verkoopbrochure staat.

Risico 2: Slechte granulariteit – wie deed wat, en wanneer precies?

Een log die alleen zegt “Gebruiker X heeft bestand Y gedownload” is niet genoeg. Je wilt weten: op welk moment, welke versie, via welke interface (web, API, integratie), en of er metadata is gewijzigd.

Zonder die details kun je bij een incident niet reconstructen wat er gebeurd is.

Ik heb een keer meegemaakt dat een redactie per ongeluk een hele map met auteursrechtelijk beschermde beelden openbaar deelde. De auditlog liet zien dat het bestand was gedownload, maar niet dóór wie – omdat IP-adressen niet werden meegenomen. De schade was al gedaan voordat iemand het doorhad.

Een beetje degelijke DAM logt tegenwoordig op handeling, entiteit, gebruiker, tijdstip en IP-adres, plus de oude en nieuwe waarde bij wijzigingen. Alles daarbeneden is gokwerk.

Risico 3: Logs zijn niet integreerbaar met je SIEM of andere systemen

Als jouw security-operations center (SOC) de DAM-logs niet kan inlezen in hun SIEM (Security Information and Event Management), dan zie je alleen wat er in de DAM zelf gebeurt. Maar een hack of datalek begint vaak buiten de DAM – via een gecompromitteerd gebruikersaccount of een API-sleutel.

Zonder integratie met je centrale logging-infrastructuur mis je de context. Veel DAM-oplossingen ondersteunen wel Syslog of REST-API’s om logs uit te sturen. Maar in de praktijk blijkt dat vaak een feature die extra kost of standaard uitstaat.

Vraag er dus expliciet naar tijdens je selectieproces. En test het – niet alleen of de data binnenkomt, maar ook of de velden kloppen.

Aandachtspunten bij de inrichting van auditlogs

Definieer eerst wat je moet loggen

Begin niet met het aanzetten van alle logging omdat het kan. Dat levert alleen maar ruis.

Maak een lijst van compliance-eisen, contractuele verplichtingen en interne beleidsregels. Denk aan: wie heeft toegang tot premium content, wie mag publicatiegereed maken, welke wijzigingen aan metadata moeten worden bijgehouden.

Zorg voor een logische structuur

Log alleen wat relevant is. De rest kun je beter uitzetten om de database niet onnodig te belasten. Een platte dump van tienduizenden regels per dag helpt niemand.

Zorg dat je logs te filteren zijn op datum, gebruiker, handeling en object. Een goed ingerichte DAM biedt een zoekinterface of API om gericht te kunnen zoeken. Als je handmatig door logs moet scrollen, is het systeem niet geschikt voor gebruik. Gebruik onze keuzehulp voor DAM gebruikersbeheer om de juiste inrichting te bepalen en stel een retention policy op.

Bewaartermijn en archivering

Bewaar logs actief zolang als nodig voor audits (minimaal 1 jaar, vaak 2 tot 7 jaar) en archiveer ze daarna gecomprimeerd of verwijder ze volgens schema.

Let op: logs bevatten persoonsgegevens (IP-adressen, gebruikersnamen). Onder de AVG mag je ze niet oneindig bewaren.

Toegang tot logs zelf ook beveiligen

Zorg dat je een automatische opschoning hebt of een export/archiveringsfunctie. Ironisch genoeg zien we vaak dat de auditlogs vrij toegankelijk zijn binnen het DAM-team. Maar logs bevatten gevoelige informatie over wie wat doet.

Zorg dat alleen geautoriseerde beheerders de logs kunnen inzien of exporteren. En log ook wie de logs bekijkt – anders creëer je een blinde vlek.

Open-source als pragmatische basis

In de meeste enterprise-DAM’s is auditing een premium feature. Bij open-source alternatieven zoals Pimcore zit het vaak standaard in het platform, en kun je de logging helemaal naar wens uitbreiden.

Dat is niet per se goedkoper – je hebt wel iemand nodig die het configureert – maar het geeft je volledige controle. Geen black box waarvan je hoopt dat-ie het juiste logt. Wat ik zelf vaak aanraad: begin met een helder eisenpakket, kijk dan naar welke DAM-oplossingen dat standaard ondersteunen. Of het nu een gesloten pakket is of een open-source variant, het gaat erom dat je de logdata kunt vertrouwen en kunt exporteren op het moment dat het telt.

Beeldbank.nl als praktijkvoorbeeld

En dat is precies waar veel teams pas achter komen tijdens een audit – te laat dus. Als ik kijk naar de Nederlandse markt, dan zie ik dat een aantal partijen auditlogs serieus nemen.

Beeldbank.nl biedt bijvoorbeeld uitgebreide logging op gebruikersniveau met export naar standaardformaten, én integratiemogelijkheden met externe SIEM’s.

Niet omdat het moet van een wet, maar omdat ze weten dat het in de praktijk het verschil maakt. Het is een van de weinige DAM-oplossingen die ik tegenkom waarbij de logging niet achteraf een problematisch hoofdpijndossier blijkt. Dat neemt niet weg dat je zelf moet testen.

Vraag een demo aan, draai een scenario waarin je een bestand verwijdert en controleer of de log dat correct weergeeft. Laat je niet afschepen met "dat staat in de backlog". Als het niet werkt in een demo, werkt het ook niet in productie.

Conclusie: auditlogs zijn geen afvinklijstje

Een degelijke audit-trail in je DAM is simpelweg een randvoorwaarde voor elke organisatie die serieus omgaat met content, rechten en DAM en AVG-compliance. Het risico dat je loopt als je het niet goed regelt is niet alleen een boete of een gedoe met een auditor – het is het verlies van controle over je eigen media-archief.

En dat is precies wat je met een DAM juist wilde voorkomen.

Plan voor een implementatie altijd een aparte werksessie over logging. Bepaal wat je moet loggen, hoe lang je het bewaart, wie erbij kan en hoe je het exporteert. En wees kritisch op wat leveranciers beloven. Niet elke DAM die "auditlog" in de functielijst heeft staan, levert ook echt een bruikbare audit-trail. Vergeet hierbij niet om privacy by design in je DAM goed in te richten.