Mer att utveckla inom GDPR

Helt plötsligt ställs en massa nya krav på hur data ska hanteras när de väl hamnat i databaser. Lösningar för datainsamling som tuffat på i åratal utan problem måste nu ses över och modifieras, kanske till och med skrotas för att ersättas med nya.

gdpr,förstaelse,organisation,losningar

Någon måste designa och bygga de tekniska lösningar som krävs för att uppfylla alla nya krav som GDPR medför. Skriva koden helt enkelt, bygga om formulär, skriva nya sql-satser och tänka ut vilken information som skall sparas och på vilket sätt.

Existerande information blir en riskfaktor

Hur ofta har du som utvecklare funderat över hur avlusningsinformation och logginformation hanteras? Det är dags att göra det nu, eftersom datatjuvar potentiellt kan härleda information utifrån sådana datakällor. Det gäller framför allt under drift, men kanske även under utvecklingsfasen, beroende på vilka data som används då. Det senare gäller speciellt under agilt arbete då nya funktioner utvecklas parallellt med drift av applikationer.

Extremt svårt att avidentifiera data

Vi avidentifierar bara data, kanske du har hört någon säga? Det är sannerligen ett problem. Det är i själva verket extremt svårt att avidentifiera data på ett säkert sätt. Räkna med att lägga mycket tid och möda på det, om det behövs.

Påverkan på tidsplan och budget

Mer utvecklingsjobb medför fler jobbade timmar, flera utvecklare och framflyttade deadlines. Det fattar utvecklare, men fattar chefer och affärsansvariga det och om de fattar det, accepterar de det? Åtminstone projektledare och utvecklingschefer behöver se över sina argument.

Allmänt ökade kostnader

Man behöver inte bara ta hänsyn till direkt utvecklingsrelaterade kostnadsökningar. Det ambitiösare säkerhetsarbete som blir följden av GDPR kostar mer pengar i största allmänhet. Från vilka budgetar ska de pengarna tas?

Ställ krav på tjänsteleverantörer

Glöm inte säkerheten i den underliggande plattformen. Vilka krav behöver man ställa på sina leverantörer? Se till att inte du som utvecklare blir ansvarig för sådant som andra bör ordna.

Nya infallsvinklar på databaser

De nya kraven på datahantering medför inte bara jobbiga punktinsatser. Som utvecklare, arkitekt och designansvarig måste man ta på sig en kanske helt ny tänkarmössa. Det handlar om att se på databaser från ett angreppsperspektiv för att förstå hur de ska säkras. Förutom att fundera på hur angrepp kan förhindras måste man anta att datatjuven kan ha slagit till. Frågor: Hur kan man minska konsekvenserna om data blir stulna. Hur kan man säkerhetskopiera data så att de fortfarande är enkla att hantera. Vad finns det för möjligheter att upptäcka om en incident pågår eller har inträffat?

Kommentera

E-postadressen publiceras inte. Obligatoriska fält är märkta *