Gobernanza y clasificación de datos en el uso compartido de archivos empresariales: lo que los DPO deben saber

No puedes proteger lo que no has clasificado. Ese principio es la base de cualquier programa maduro de protección de datos, y ahora está integrado en los requisitos regulatorios que aplican directamente a entornos regulados de uso compartido de archivos. El RGPD y su principio de minimización de datos, la obligación de NIS 2 de implementar medidas de seguridad adecuadas para datos categorizados, y el marco de administración de riesgos TIC de DORA parten de la premisa de que las organizaciones saben qué datos poseen, cuán sensibles son, quién los ha manipulado y bajo qué condiciones pueden circular.

El reto operativo es que la gobernanza de la clasificación suele tratarse como un problema de gestión documental en vez de un control de plataforma. Las organizaciones invierten en taxonomías de clasificación, redactan políticas de sensibilidad y realizan capacitaciones para el personal, para luego descubrir que la plataforma de uso compartido de archivos donde gestionan sus datos más sensibles no tiene mecanismos para aplicar esas políticas, ni un registro auditable de clasificación que un auditor pueda revisar, ni vinculación entre la sensibilidad de los datos y las decisiones de acceso. El programa de clasificación existe en papel; la plataforma lo ignora en la práctica.

Este artículo está dirigido a Responsables de Privacidad de Datos (DPO) y líderes de protección de datos que necesitan entender cómo una plataforma moderna de uso compartido de archivos empresariales puede —y debe— respaldar sus obligaciones de clasificación y gobernanza. Explica cómo son los controles de plataforma conscientes de la clasificación, qué obligaciones regulatorias cubren y cómo Kiteworks los implementa según capacidades documentadas.

Resumen Ejecutivo

Idea principal: La clasificación de datos en el uso compartido de archivos empresariales no es solo poner una etiqueta en un archivo. Una gobernanza eficaz requiere cuatro capacidades interconectadas: un esquema de clasificación que el cliente pueda definir y mantener, etiquetas de sensibilidad que persistan durante el movimiento de los datos, controles de plataforma que apliquen decisiones de política basadas en esas etiquetas y un registro auditable que documente cada evento de clasificación para revisión regulatoria. La mayoría de plataformas implementan una o dos de estas; una gobernanza real exige que las cuatro funcionen juntas.

Por qué te interesa: Los artículos 5 y 17 del RGPD, el artículo 21 de NIS 2 y los marcos de evaluación de soberanía de datos exigen que las organizaciones demuestren que los datos sensibles están categorizados, que el acceso está controlado en proporción a la sensibilidad, que los datos pueden eliminarse bajo demanda con evidencia verificable y que existe un registro completo de actividad disponible para las autoridades supervisoras. Una plataforma de uso compartido de archivos sin controles conscientes de la clasificación obliga al DPO a crear controles compensatorios fuera de la plataforma, generando brechas de auditoría y riesgos de cumplimiento difíciles de cerrar sin una gobernanza nativa de la plataforma.

5 puntos clave

1. La clasificación sin aplicación es un pasivo de cumplimiento, no un activo. Una etiqueta de sensibilidad que existe en un archivo pero no influye en ninguna decisión de acceso, regla de DLP o restricción de uso compartido no brinda protección real de datos. Los reguladores que revisan un incidente preguntarán si la etiqueta cambió algo, y «clasificamos pero no aplicamos» no es una respuesta defendible. La lista de verificación del DPO debe incluir la verificación de que las etiquetas impulsan al menos una decisión de control observable en la plataforma.
2. El soporte de etiquetas de Microsoft Information Protection solo es valioso si la plataforma receptora las conserva y actúa en consecuencia. Muchas organizaciones aplican etiquetas de sensibilidad MIP en Microsoft 365 y asumen que esas etiquetas viajan con los datos. Si una plataforma ajena a Microsoft lee, respeta y aplica la etiqueta heredada —o la elimina silenciosamente— es una pregunta que hay que hacer explícitamente. La integración de MIP a nivel de plataforma que conserva el estado de la etiqueta y canaliza los datos a través de controles conscientes de la clasificación es una capacidad distinta a simplemente aceptar archivos etiquetados.
3. Un registro auditable de clasificación es un entregable regulatorio, no un simple registro interno de TI. Bajo el RGPD y NIS 2, los DPO deben poder demostrar a las autoridades supervisoras que los eventos de clasificación —etiqueta aplicada, cambiada o eliminada— se registran con suficiente detalle para reconstruir la historia de un dato concreto. Un registro de auditoría que documenta 632 tipos de eventos distintos, incluyendo eventos de clasificación de contenido, es un recurso que el DPO puede usar realmente en una revisión regulatoria. Los registros genéricos de sistema no lo son.
4. El crypto-shredding mediante BYOK te da un mecanismo de borrado auditable y controlado por el cliente, pero su validez bajo el artículo 17 del RGPD varía según la jurisdicción. El derecho de supresión exige una eliminación verificable. En un entorno de almacenamiento cifrado, destruir la clave de cifrado hace que los datos asociados sean permanentemente ilegibles sin requerir evidencia de eliminación a nivel de byte. Cuando el cliente posee la clave —mediante Bring Your Own Key o Hold Your Own Key— el evento de eliminación está totalmente bajo su control y la evidencia es generada por el cliente, no por el proveedor. La aceptación de la destrucción de la clave como equivalente a la eliminación no es uniforme entre las autoridades supervisoras de la UE, así que las organizaciones deben obtener asesoría legal específica para su jurisdicción.
5. Las taxonomías de clasificación propiedad del cliente son la cuestión de soberanía de gobernanza que rara vez se pregunta en compras. Si el cliente puede definir sus propios niveles de sensibilidad, nombres de categorías y jerarquía de clasificación —o si se ve obligado a adoptar el esquema fijo del proveedor— determina quién controla realmente la gobernanza de datos. Una taxonomía definida por el proveedor crea dependencia; una taxonomía creada por el cliente y aplicada por la plataforma es una verdadera capacidad de gobernanza.

El caso regulatorio para el uso compartido de archivos consciente de la clasificación

Las obligaciones de clasificación de datos no son nuevas, pero su contexto de aplicación ha cambiado notablemente. El artículo 5 del RGPD sobre minimización y limitación de propósito, vigente desde 2018, exige que las organizaciones solo conserven los datos personales necesarios para un propósito definido y eviten su uso más allá de ese propósito. En un entorno de uso compartido de archivos, esa obligación solo tiene fuerza si la plataforma puede aplicar límites de retención, restringir el acceso a grupos de usuarios relevantes y aportar evidencia de que los controles funcionan.

RGPD, NIS 2 y DORA: Obligaciones de clasificación superpuestas

El artículo 5 del RGPD exige que los datos personales sean «adecuados, pertinentes y limitados a lo necesario en relación con los fines para los que se tratan» —el principio de minimización de datos— y que se «conserven en una forma que permita la identificación de los interesados durante no más tiempo del necesario». No son requisitos de documentación. Exigen controles operativos: clasificación que identifique categorías de datos personales, restricciones de acceso proporcionales a la sensibilidad y aplicación de retención que realmente elimine o haga inaccesibles los datos fuera de su periodo de conservación.

El artículo 17 del RGPD —el derecho de supresión— añade otro requisito operativo. Cuando un interesado ejerce su derecho de supresión, el responsable debe demostrar que los datos han sido eliminados o hechos permanentemente inaccesibles. En un entorno distribuido de uso compartido de archivos donde los datos pueden existir en múltiples versiones, copias compartidas y respaldos del sistema, la «eliminación» es técnicamente compleja. Las plataformas que permiten el borrado criptográfico —destruyendo la clave de cifrado que protege un archivo o conjunto de archivos— ofrecen un mecanismo técnicamente sólido y auditable para evidenciar la obligación del artículo 17, siempre que la autoridad supervisora correspondiente acepte la destrucción de la clave como equivalente a la eliminación.

El artículo 21 de NIS 2 exige que las entidades en el alcance implementen «medidas técnicas y organizativas apropiadas y proporcionales» para gestionar los riesgos, incluyendo explícitamente «políticas de análisis de riesgos y seguridad de los sistemas de información». La guía de la Agencia de Ciberseguridad de la Unión Europea (ENISA) sobre la implementación de NIS 2 trata la categorización de datos como un requisito previo para seleccionar medidas de seguridad proporcionales: no puedes aplicar medidas proporcionales al riesgo si no has categorizado los datos para evaluar su sensibilidad. Las autoridades competentes que revisen la implementación de NIS 2 buscarán evidencia de un esquema de clasificación operativo, no solo un documento de política de clasificación.

El marco de administración de riesgos TIC de DORA, aplicable a entidades financieras y sus proveedores críticos de TIC a partir de enero de 2025, exige que las entidades «identifiquen y clasifiquen los activos TIC» e «identifiquen todas las fuentes de riesgo TIC». Para plataformas de uso compartido de archivos que gestionan datos financieros, esta obligación aplica tanto a la organización como —mediante requisitos contractuales— al proveedor de la plataforma. Una plataforma que no permita clasificar los datos que almacena y transmite crea una brecha de cumplimiento con DORA que la función de riesgos TIC de la entidad financiera debe cerrar.

Soberanía de datos e IA: el requisito de gobernanza

Los requisitos de soberanía de datos e IA abordan la capacidad del cliente para mantener el control sobre el tratamiento de datos, incluyendo la clasificación y la gobernanza. Esto abarca la capacidad del cliente para definir esquemas de categorización, aplicar controles de acceso basados en la sensibilidad, mantener evidencia de auditoría sobre decisiones de gestión y ejercer derechos de eliminación sin dependencia del proveedor. Una plataforma de uso compartido de archivos que respalde estos requisitos le da al DPO evidencia documentada y verificable de que la postura de clasificación de datos de la organización se extiende hasta la capa de uso compartido de archivos, y no solo a los sistemas de gestión documental o CRM que suelen recibir más atención en gobernanza.

Nota regulatoria: Este artículo refleja información general sobre obligaciones regulatorias. Para orientación vinculante sobre cómo aplican los requisitos de RGPD, NIS 2 o DORA en las circunstancias específicas de tu organización, consulta con tu asesor legal o de protección de datos. La interpretación regulatoria varía según jurisdicción, sector y autoridad supervisora.

Arquitectura de clasificación: lo que exige la gobernanza a nivel de plataforma

Entender cómo Kiteworks implementa la gobernanza de clasificación requiere comprender cómo es una arquitectura de clasificación completa y por qué las implementaciones parciales generan riesgos residuales. La gobernanza de clasificación en una plataforma de uso compartido de archivos abarca cuatro capas: definición de taxonomía, aplicación e herencia de etiquetas, aplicación de controles basados en etiquetas y evidencia de auditoría. Una brecha en cualquier capa debilita a las demás.

Definición de taxonomía: esquemas de clasificación creados por el cliente

La base de cualquier programa de gobernanza es la taxonomía de clasificación: el conjunto de niveles de sensibilidad, categorías de datos y requisitos de manejo que la organización define para reflejar sus tipos de datos reales y su perfil de riesgo. La taxonomía de una organización de servicios financieros será muy distinta a la de un proveedor de salud, y diferente a la de un contratista de defensa. Una plataforma que impone una taxonomía fija definida por el proveedor obliga a cada cliente a adaptar sus requisitos de gobernanza a un esquema que puede no ajustarse a su entorno regulatorio, sus tipos de datos internos o las expectativas de su autoridad supervisora.

Kiteworks permite definir esquemas de clasificación personalizados. Los clientes pueden crear sus propias categorías de datos y niveles de sensibilidad desde la interfaz administrativa. El alcance de la autoría de taxonomía vía API —que permite la gestión programática de taxonomías integrada con la herramienta de gobernanza del cliente— conviene confirmarlo con el equipo de Kiteworks para necesidades específicas de implementación. Para organizaciones que gestionan taxonomías de clasificación en varios sistemas, la gestión de taxonomía vía API reduce la administración manual y elimina el riesgo de divergencia entre el esquema de la plataforma y la taxonomía maestra de la organización.

Pregunta a verificar: ¿La taxonomía de clasificación de tu organización —incluyendo nombres personalizados de niveles de sensibilidad, definiciones de categorías y reglas de manejo asociadas— puede definirse y mantenerse completamente a través de la interfaz de administración de Kiteworks sin recurrir al equipo técnico de Kiteworks? Para organizaciones con esquemas de clasificación complejos o en constante actualización, la autoría de taxonomía vía API puede ser un requisito específico. Confirma el alcance de la autogestión de taxonomía para tu modelo de implementación antes de finalizar el diseño de gobernanza.

Integración de etiquetas de Microsoft Information Protection

Para organizaciones que ya usan Microsoft 365 y su etiquetado nativo de sensibilidad, la pregunta no es si crear un nuevo esquema de clasificación, sino si la plataforma de uso compartido de archivos respetará las etiquetas ya aplicadas. Las etiquetas de sensibilidad MIP —aplicadas mediante Microsoft Purview Information Protection— acompañan a los documentos como metadatos persistentes. Cuando un documento etiquetado sale del ecosistema Microsoft 365 e ingresa a una plataforma de terceros, suelen ocurrir dos fallos: la plataforma elimina la etiqueta silenciosamente, creando una copia sin clasificar; o la plataforma almacena la etiqueta como metadato pero no toma ninguna acción basada en ella.

Kiteworks lee, respeta y conserva las etiquetas de sensibilidad MIP. Un documento que ingresa a Kiteworks con una etiqueta MIP mantiene esa etiqueta; el estado de la etiqueta es visible, rastreable en el registro de auditoría y se integra en las decisiones de control de acceso basado en atributos de la plataforma. Las etiquetas también pueden aplicarse o heredarse dentro de Kiteworks según reglas de clasificación: un documento que coincide con patrones de contenido definidos puede recibir automáticamente una etiqueta de sensibilidad, sin intervención del usuario. También se admite la aplicación manual de etiquetas por parte de los usuarios, permitiendo que el criterio humano actúe donde la clasificación automática no sea suficiente o donde el contenido requiera reclasificación según el contexto.

Para organizaciones que no operan en un entorno Microsoft 365, Kiteworks ofrece un sistema nativo de etiquetado —Kiteworks Tags— que cumple la misma función de gobernanza de forma independiente a MIP. Las Kiteworks Tags pueden definirse por implementación, aplicarse automáticamente mediante reglas de política al cargar o recibir archivos y usarse como condiciones de ABAC y desencadenantes de DLP igual que las etiquetas MIP. Así, las organizaciones que operan fuera de Microsoft pueden construir una arquitectura de clasificación completa y aplicada por políticas directamente en Kiteworks, sin depender de sistemas externos de etiquetado.

La vinculación entre las etiquetas de clasificación —ya sean MIP o Kiteworks Tags— y el motor DLP de Kiteworks es especialmente relevante para la gobernanza. Los datos clasificados como sensibles —por etiqueta MIP, Tag de Kiteworks, clasificación manual o regla automática— pueden activar políticas DLP que restrinjan el uso compartido, requieran aprobaciones, apliquen marcas de agua o limiten el acceso solo a visualización. Esto significa que la etiqueta de sensibilidad no solo describe el dato, sino que gobierna activamente lo que puede hacerse con él. El esquema de clasificación se convierte en un control operativo, no en un simple ejercicio documental.

Etiquetas de sensibilidad y control de acceso: de la clasificación a la aplicación

La gobernanza de la clasificación obtiene su valor de la aplicación. Una etiqueta de sensibilidad que no influye en ninguna decisión de la plataforma es un trámite administrativo que no cumple ninguna obligación regulatoria en la práctica. La pregunta de gobernanza para los DPO no es «¿la plataforma admite etiquetas?» sino «¿qué hace la plataforma de forma diferente por la etiqueta?»

Control de acceso basado en atributos: autorización impulsada por etiquetas

Kiteworks implementa control de acceso basado en atributos (ABAC) junto con control de acceso basado en roles (RBAC). La diferencia es clave para la gobernanza de la clasificación: RBAC determina lo que un usuario puede hacer según su rol; ABAC determina a qué puede acceder un usuario según los atributos tanto del usuario como del contenido. Cuando las etiquetas de clasificación se incorporan como atributos de contenido en el modelo ABAC, las decisiones de acceso pueden basarse directamente en la sensibilidad.

En la práctica, esto significa que el rol de un usuario puede permitirle acceder a una carpeta, pero una política ABAC puede restringir el acceso a archivos específicos dentro de esa carpeta según su etiqueta de sensibilidad, sin requerir gestión manual de permisos por archivo. Un documento etiquetado como Restringido o Confidencial puede estar sujeto a una política de acceso diferente a un documento No Clasificado en la misma ubicación. Esto crea una capa de gobernanza que opera sobre atributos de contenido en vez de solo sobre la jerarquía organizativa, lo que es más flexible y más alineado con cómo se plantean las obligaciones regulatorias (proteger los datos según su sensibilidad, no solo por dónde se almacenan).

Pregunta a verificar: Confirma con Kiteworks las políticas ABAC disponibles en tu modelo de implementación, en especial si una etiqueta de sensibilidad puede activar directamente una decisión de denegar acceso a usuarios que no cumplen los requisitos de manejo de la etiqueta, independientemente de los permisos RBAC a nivel de carpeta. La integración entre etiquetas MIP, atributos ABAC y decisiones de denegación de acceso es la vinculación de gobernanza que convierte la clasificación en aplicación. La arquitectura lo soporta; las opciones de configuración específicas para tu implementación conviene confirmarlas durante el diseño.

Integración DLP: la clasificación como desencadenante de políticas

La Prevención de Pérdida de Datos en el contexto de uso compartido de archivos significa impedir que datos sensibles lleguen a destinos o destinatarios que no cumplen los requisitos de manejo. La integración DLP de Kiteworks usa las etiquetas de clasificación como desencadenantes de políticas. Los datos etiquetados como sensibles pueden estar sujetos a reglas que bloqueen el uso compartido externo, requieran aprobación gerencial antes de la transmisión, apliquen marcas de agua a todas las copias exportadas o limiten al destinatario a solo visualización sin descarga.

No son controles cosméticos. Una regla DLP que impide que un empleado comparta un documento etiquetado como Restringido con un externo sin aprobación es una implementación operativa del principio de limitación de propósito del RGPD: el documento solo puede compartirse con destinatarios y en contextos consistentes con el propósito para el que se recolectaron los datos. La etiqueta de clasificación codifica la decisión de sensibilidad tomada previamente (por política, regla automática o autor del documento); la regla DLP la aplica en el momento del uso compartido. La evidencia de auditoría del DPO incluye tanto el historial de etiquetas como los eventos de aplicación DLP.

Clasificación consciente de la residencia

Para organizaciones con obligaciones de residencia de datos —comunes en EMEA bajo RGPD, el estándar alemán BSI C5 y requisitos sectoriales— la clasificación puede vincularse con controles de residencia. El contenido clasificado como sujeto a restricciones jurisdiccionales específicas puede dirigirse a ubicaciones de almacenamiento que cumplan esos requisitos. Las opciones de implementación multi-instancia y geográficamente distribuidas de Kiteworks permiten que la aplicación de residencia opere a nivel de plataforma, sin depender de revisiones posteriores sobre dónde terminó el dato clasificado. La combinación de clasificación, conciencia de residencia y control de acceso crea un entorno de gobernanza dentro del cual los datos regulados pueden circular sin necesidad de supervisión manual constante.

Registro auditable de clasificación: evidencia para revisión regulatoria

El registro auditable es donde las afirmaciones de gobernanza se enfrentan al escrutinio regulatorio. Cuando una autoridad supervisora, un auditor interno o un DPO que realiza una revisión anual pregunta qué ocurrió con un dato clasificado concreto, la respuesta debe provenir de un registro estructurado e inalterable, no de inferencias reconstruidas o recuerdos del administrador del sistema.

Registro de auditoría de 632 eventos: eventos de clasificación en contexto

Kiteworks mantiene un registro de auditoría integral que abarca 632 tipos de eventos distintos. Los eventos de clasificación —etiqueta aplicada, cambiada o eliminada— se registran junto con el contexto completo de actividad: identidad del usuario, marca de tiempo, identificador de contenido, origen y destino, y contexto de sesión. Así, el registro de auditoría de un documento sensible no es solo un historial de clasificación aislado; es un registro completo de actividad que muestra quién aplicó la etiqueta, qué acciones se realizaron sobre el dato antes y después de la clasificación y si hubo eventos gobernados por políticas (disparador DLP, restricción de acceso, flujo de aprobación) asociados al estado de clasificación.

Para los DPO, esto es una capacidad fundamental. En una investigación regulatoria, demostrar que los controles de clasificación funcionan requiere más que mostrar la etiqueta actual de un archivo. Hay que demostrar el historial: cuándo se aplicó la etiqueta, por quién, si alguna vez se cambió, qué decisiones de acceso se vieron influidas por la etiqueta y si hubo eventos DLP activados por la clasificación. El registro de auditoría de 632 eventos proporciona la materia prima para esta reconstrucción. Los informes filtrados por política del registro de auditoría —que permiten a los administradores de cumplimiento aislar eventos por política o etiqueta de contenido específica— están disponibles con la licencia Advanced Governance. La cuestión de si el registro puede exportarse en un formato adecuado para presentación regulatoria —estructurado, firmado y formateado para la autoridad supervisora— es un detalle de configuración e implementación que conviene confirmar.

Nota sobre el registro auditable: El registro de auditoría de 632 eventos es un registro basado en actividad: captura quién hizo qué, cuándo y sobre qué dato. Esto proporciona una forma de linaje de contenido a través de la capa de uso compartido de archivos: un registro completo de acceso, modificación, uso compartido y eventos de clasificación durante el ciclo de vida del contenido en la plataforma. No es un mapa de linaje de datos en el sentido de ingeniería de datos (seguimiento de transformaciones a través de sistemas y etapas de procesamiento). Las organizaciones que requieran linaje de datos completo entre sistemas deberán complementar el registro de Kiteworks con herramientas de linaje en la infraestructura de datos más amplia.

Registro inalterable y admisibilidad regulatoria

Un registro de auditoría solo tiene valor regulatorio si se puede demostrar su integridad. Un registro que un administrador puede modificar, truncar o exportar selectivamente no es una base fiable para la revisión de una autoridad supervisora. El registro auditable de Kiteworks está diseñado para soportar registros inalterables. Para organizaciones con implementaciones on-premises, la infraestructura del registro está bajo control del cliente, lo que permite aplicar controles de integridad propios (almacenamiento de solo escritura, reenvío externo de registros, firma criptográfica) sin depender de las garantías del proveedor sobre la integridad del registro. La capacidad de reenviar eventos de auditoría a un SIEM controlado por el cliente en tiempo real brinda a las áreas de seguridad y cumplimiento un registro independiente e inalterable.

Retención, eliminación y la implementación del artículo 17 del RGPD

La retención y la eliminación son de los aspectos más exigentes operativamente en la gobernanza de datos para entornos de uso compartido de archivos. El contenido se acumula rápidamente; las versiones se multiplican; los archivos eliminados pueden persistir en respaldos; y cuando un interesado ejerce su derecho de supresión del artículo 17, demostrar que la eliminación realmente ocurrió requiere más que un registro de la acción de borrado.

Políticas de retención configurables

Kiteworks permite políticas de retención configurables por el cliente. El Acuerdo de Procesamiento de Datos incluye procedimientos de devolución y eliminación de datos que rigen cómo se gestionan los datos al terminar el contrato, un requisito básico para cualquier acuerdo de procesamiento conforme al RGPD. Para la gestión operativa de la retención —establecer periodos de retención por tipo de dato, nivel de sensibilidad o carpeta— conviene verificar el alcance de la autogestión por parte del cliente durante la implementación. Las organizaciones con calendarios de retención complejos (varias categorías con diferentes periodos, requisitos de retención legal, disparadores automáticos de eliminación) deben confirmar que las capacidades de retención de la plataforma se alinean con su política antes de la implementación, y no descubrir brechas durante una auditoría regulatoria.

Pregunta a verificar: Confirma con Kiteworks la granularidad de los controles de retención configurables por el cliente en tu modelo de implementación, en concreto si los periodos de retención pueden establecerse por categoría de dato o nivel de sensibilidad, y si se admite la eliminación automática (en vez de marcar para revisión manual) para datos que han superado su periodo de retención.

Crypto-shredding: BYOK y HYOK como mecanismos de eliminación

Para organizaciones con acuerdos Bring Your Own Key (BYOK) o Hold Your Own Key (HYOK), Kiteworks permite un enfoque criptográfico de eliminación que es robusto técnicamente y amigable para auditorías. Bajo BYOK, el cliente posee las claves de cifrado que protegen los datos almacenados. Los datos clasificados como sujetos a eliminación —porque corresponden a un interesado que ejerció su derecho del artículo 17, o porque han llegado al final de su periodo de retención— pueden ser eliminados mediante crypto-shredding: la clave de cifrado que protege esos datos se destruye, haciendo que los datos cifrados sean permanentemente e irreversiblemente ilegibles.

El crypto-shredding ofrece varias ventajas frente a la eliminación tradicional. Primero, el evento de eliminación está totalmente bajo control del cliente —no hay dependencia del proveedor para ejecutar el borrado, ni ventana entre la solicitud y la eliminación durante la cual los datos sigan accesibles para la infraestructura del proveedor. Segundo, la evidencia es generada por el cliente: el evento de destrucción de la clave queda registrado en el sistema de gestión de claves del cliente, proporcionando evidencia verificable para auditorías sin depender de la declaración del proveedor. Tercero, resuelve el problema de datos residuales: incluso si los bytes cifrados permanecen en un respaldo o almacenamiento distribuido, sin la clave son indistinguibles computacionalmente de ruido aleatorio —el dato está, en efecto, eliminado.

La combinación de identificación impulsada por la clasificación (¿qué datos están sujetos a eliminación?) y crypto-shredding mediante BYOK (¿cómo se ejecuta y evidencia la eliminación?) constituye una base técnicamente sólida y auditable para cumplir el artículo 17 del RGPD en la capa de uso compartido de archivos. Dado que la aceptación del crypto-shredding como equivalente a la eliminación no es uniforme entre autoridades supervisoras de la UE, las organizaciones deben confirmar su validez en su jurisdicción con asesoría legal antes de adoptarlo como mecanismo principal de eliminación.

Cómo aborda Kiteworks la gobernanza de datos: puntos de diferenciación

Varias características distinguen la arquitectura de gobernanza de datos de Kiteworks frente a plataformas que tratan la clasificación como un complemento y no como una capacidad estructural.

La clasificación como infraestructura de plataforma, no integración

En muchas plataformas empresariales, la clasificación se gestiona integrando una herramienta DLP o de clasificación de terceros que opera junto a la plataforma e inspecciona los datos a posteriori. La decisión de clasificación se toma externamente; la plataforma recibe una señal y puede o no actuar en consecuencia. La vinculación es frágil, solo auditable a través de dos sistemas y dependiente de que la integración siga operativa.

Kiteworks trata la clasificación como parte de su propio modelo de datos. El estado de la etiqueta MIP es un atributo de primer nivel que la plataforma lee de forma nativa, almacena junto al dato, muestra en el registro de auditoría y evalúa en decisiones de política ABAC. Las políticas DLP se definen dentro de la plataforma y se aplican en el momento de la operación —uso compartido, descarga, transmisión— en vez de en un punto de inspección perimetral. La arquitectura de clasificación es la arquitectura de la plataforma, no una capa añadida.

Gobernanza durante todo el ciclo de vida del contenido

La gobernanza de datos en el uso compartido de archivos abarca todo el ciclo de vida: ingreso (¿de dónde viene el archivo, con qué etiqueta?), almacenamiento (¿qué estado de clasificación tiene?), acceso (¿quién accedió, bajo qué política, con qué decisión ABAC?), transmisión (¿a dónde fue, bajo qué gobernanza DLP?) y eliminación (¿cuándo y cómo se destruyó, con qué evidencia?). Una capacidad de gobernanza que solo cubre algunas de estas etapas deja brechas que aparecen justo cuando el escrutinio regulatorio es mayor —cuando algo ha salido mal y se necesita la reconstrucción completa de la auditoría.

La combinación de integración de etiquetas MIP, control de acceso impulsado por ABAC, gobernanza de transmisión mediante DLP, registro de auditoría de 632 eventos en todas las etapas y crypto-shredding habilitado por BYOK de Kiteworks proporciona cobertura durante todo el ciclo de vida. No implica que todas las opciones de configuración estén disponibles en todos los modelos de implementación —los detalles varían y deben confirmarse durante la compra— pero la cobertura arquitectónica es completa, a diferencia de muchas plataformas competidoras.

Certificación y posición regulatoria

Las capacidades de gobernanza de Kiteworks son evaluadas y certificadas según múltiples estándares independientes relevantes para EMEA y entornos regulados internacionales. BSI C5 (el Catálogo de Controles de Cumplimiento de Computación en la Nube de la Oficina Federal de Seguridad de la Información de Alemania) evalúa controles de gestión de datos, acceso y registros operativos directamente relacionados con la gobernanza de clasificación. ISO 27001 cubre el sistema de gestión de seguridad de la información donde operan los controles de clasificación y gobernanza. Cyber Essentials Plus proporciona validación reconocida por el gobierno del Reino Unido. IRAP (Information Security Registered Assessors Program) respalda implementaciones para el gobierno australiano y sectores regulados. FedRAMP High In Process cubre requisitos federales de EE. UU. SOC 2 Type II brinda garantía independiente sobre controles de seguridad, incluyendo gestión de accesos y registros de auditoría.

Para los DPO que preparan documentación regulatoria, la disponibilidad de informes de evaluación de terceros sobre estos marcos proporciona corroboración independiente de las afirmaciones de gobernanza de la plataforma, evidencia que no depende solo de la autoafirmación del proveedor.

Conclusión

La gobernanza y clasificación de datos en un entorno de uso compartido de archivos no es una casilla a marcar en la compra, sino la base sobre la que dependen todos los demás controles de protección de datos. A medida que las autoridades supervisoras bajo RGPD, NIS 2 y DORA elevan sus expectativas sobre la gobernanza demostrable y aplicada operativamente, la capa de uso compartido de archivos ya no puede tratarse como fuera del alcance del programa de protección de datos de la organización. La arquitectura de clasificación de Kiteworks —que combina taxonomías definidas por el cliente, preservación y aplicación de etiquetas MIP, control de acceso impulsado por ABAC, integración DLP, registro de auditoría integral y crypto-shredding respaldado por BYOK— proporciona los elementos para una postura de gobernanza defendible por el DPO durante todo el ciclo de vida de los datos. Las organizaciones que evalúan o revisan su gobernanza en el uso compartido de archivos deben preguntarse no si la plataforma admite clasificación, sino si la plataforma la aplica, y si la evidencia puede resistir el escrutinio regulatorio.

Preguntas frecuentes