Protección de datos y desarrollo de software

Los desarrolladores de software se enfrentan a menudo a los obstáculos de la protección de datos. Aquí surge rápidamente la impresión de que la protección de datos y el desarrollo de software son dos temas incompatibles.

Por ello, a continuación presentamos brevemente algunos puntos de orientación para desarrolladores de software.

Privacidad desde el diseño (Art. 25 I GDPR)

La limitación del almacenamiento, la minimización de los datos, la confidencialidad y la integridad son sólo los principios más obvios de la protección de datos que sólo pueden integrarse a posteriori con gran esfuerzo. Por lo tanto, la acción preventiva es la clave. Ya en la arquitectura de la aplicación informática debe establecerse un alto nivel de protección de datos para no rebasar el marco legal con las infinitas posibilidades técnicas.

Tener en cuenta todos los aspectos de la protección de datos en una fase temprana del desarrollo también ahorra enormes cantidades de costes que se producirían si hubiera que rehacer un software acabado que viola la protección de datos.

Si el software se desarrolla de forma que el usuario pueda ver claramente qué datos se recopilan y que se hace de forma transparente, minimizada y con una finalidad específica, no sólo se respetan importantes principios de protección de datos (transparencia, art. 5 I lit. a DSGVO; minimización de datos, art. 5 I lit. c DSGVO; limitación de la finalidad, art. 5 I lit. b DSGVO), sino que también aumenta la confianza del usuario en el software. Al final, esto representa de nuevo un valor económico.

En cuanto a la transparencia, cabe señalar que todos los flujos de datos deben presentarse al interesado. Esto incluye, en particular, los flujos de datos a terceros, sobre los que debe facilitarse información en cualquier caso (art. 13 del RGPD).

Esto significa que el objetivo del desarrollo de software debe ser siempre evitar en la medida de lo posible la recopilación de datos personales y, en caso de recopilación, recoger sólo los datos realmente necesarios para el fin perseguido. Las decisiones en este ámbito suelen ser responsabilidad de la parte interesada correspondiente y, por tanto, deben debatirse detalladamente con ella.

Seguridad de los datos desde su recogida hasta su supresión

La seguridad de los datos también debe garantizarse a lo largo de todo el "ciclo de vida del software". Los datos deben estar protegidos desde su recogida, durante su almacenamiento y hasta su supresión. Aquí se expresan los principios de confidencialidad e integridad (art. 5 I lit. f DSGVO).

Por un lado, hay que impedir el acceso no autorizado a los datos. La elección de una norma de cifrado adecuada es tan esencial como la aplicación de controles de acceso. También hay que tener en cuenta las copias de seguridad y la capacidad de recuperación para garantizar la disponibilidad de los datos.

La obligación de garantizar la protección de datos mediante este tipo de medidas se aplica normalmente al propio desarrollador de software, cuyas obligaciones contractuales de desarrollo de software para el cliente (que suele ser la parte responsable) se ven afectadas en este caso.

Supresión correcta

Si la finalidad del tratamiento deja de aplicarse, pero a más tardar cuando expiren los periodos de conservación, los datos correspondientes deberán suprimirse inmediatamente. Si no se hace, las autoridades de protección de datos pueden imponer fuertes multas.

Por tanto, la supresión de datos también debe tenerse en cuenta en una fase temprana de la planificación del programa informático. Un sistema de borrado automático es una buena idea en este caso.

Anonimización como alternativa a la supresión

Si la supresión de los datos correspondientes no es técnicamente posible o razonable, los datos también pueden anonimizarse. Esto debe hacerse de tal manera que ya no sea posible establecer una referencia personal. La anonimización suele ser más fácil de aplicar que la supresión debido a la complejidad de los datos y su presentación.

Cabe señalar que la seudonimización no es suficiente para ello. La seudonimización significa que los datos dejan de tener una referencia personal sin la adición de información adicional, pero ésta puede establecerse a través de la información adicional. Existe seudonimización, por ejemplo, si los datos sobre una persona se almacenan con un número de identificación individual (por ejemplo, un número de cliente) en lugar de en relación con el nombre de la persona. Esto no cumple los requisitos de la obligación de supresión, pero la anonimización real sí.

Privacidad por defecto (Art. 25 II DSGVO)

Si existe un marco básico de acuerdo con la "privacidad desde el diseño", también debe tenerse en cuenta el principio de "privacidad por defecto" (es decir, la protección de datos a través de configuraciones por defecto favorables a la protección de datos). Estos ajustes por defecto pueden garantizar que sólo se traten los datos necesarios para el fin especificado. Por lo tanto, los ajustes por defecto deben representar siempre el menor ámbito de procesamiento posible.

Ejemplos

En un sistema CRM (Customer Relationship Management), deben definirse distintas funciones de usuario mediante un sistema de autorización detallado, de modo que cada usuario sólo tenga acceso a los datos necesarios para su área de trabajo.

Si se trata del envío de boletines informativos o similares, el usuario debe poder registrarse para ello mediante una opción de opt-in. Si el usuario tiene que desactivar activamente la opción (opt-out), esto no se ajusta a la protección de datos.

Consejos para la práctica

Confíe en lo que ya se ha probado: Por lo general, los componentes y marcos generalizados suelen ser más resistentes a los controles externos que los menos generalizados. Sin embargo, esto no debería excluir per se el uso de componentes propios comparables en su lugar. Sin embargo, especialmente en categorías como el cifrado y otros componentes de seguridad, deben utilizarse normas de aplicación general.

La comunicación es importante. Como desarrollador de software, es importante señalar los requisitos de protección de datos desde el principio en las conversaciones con arquitectos, partes interesadas y, si es necesario, otros desarrolladores, para que se tengan en cuenta y se planifiquen en una fase temprana. Esto ahorra mucho esfuerzo y costes y facilita la interacción entre la protección de datos y el desarrollo de software.