Plantilla de Clasificación de Datos

Visión General

No todos los datos son iguales. Un post de blog de marketing público y el número de tarjeta de crédito de un cliente no merecen la misma protección, pero los equipos suelen aplicar cifrado y controles de acceso uniformes porque nadie definió la diferencia. La clasificación de datos crea un vocabulario compartido para el riesgo: los datos públicos pueden ser abiertos, los internos necesitan control de acceso, los confidenciales necesitan cifrado y los restringidos necesitan cifrado más un acceso estricto por necesidad de saber. Sin ella, los ingenieros acaban sobreprotegiendo todo (caro y lento) o subprotegiendo todo (riesgo de brecha).

Esta plantilla te da un esquema de cuatro niveles, un inventario de datasets, reglas de manejo por nivel y un registro de excepciones. Cópiala en tu wiki o manual de seguridad, rellena los placeholders y tendrás una política de clasificación que tu equipo puede aplicar de verdad.

Cuándo Usar

Usa esta plantilla cuando:

• Estás diseñando una política de almacenamiento o control de acceso de datos y necesitas etiquetas consistentes entre equipos
• Los marcos de cumplimiento (SOC 2, GDPR, HIPAA, PCI DSS) exigen manejo documentado de datos
• Ocurrió una brecha o filtración y te das cuenta de que nadie acordó qué significaba “sensible”
• Incorporas a un nuevo ingeniero de seguridad o DPO que necesita entender el esquema existente
• Estás definiendo el alcance de un despliegue de DLP y necesitas las etiquetas que la herramienta va a aplicar

No uses esta plantilla cuando tu organización ya sigue un esquema obligatorio — contratistas gubernamentales sujetos a un modelo de autorización (Unclassified/CUI/Secret) o comercios PCI dentro de un ámbito CDE existente deberían adaptar la taxonomía mandada. Si tu necesidad inmediata es el consentimiento y los derechos de los titulares más que el etiquetado, consulta la receta Privacidad de Datos y Cumplimiento GDPR.

La Plantilla

Copia el markdown de abajo y reemplaza los placeholders. El documento de clasificación en sí debería vivir donde tu equipo guarda las políticas de seguridad — una página de wiki o un repositorio versionado funcionan; lo importante es que los ingenieros lo encuentren durante las revisiones de diseño.

# Clasificación de Datos: <Sistema / Dataset>

## 1. Definiciones de Clasificación

| Nivel | Descripción | Ejemplos | Requisitos de Manejo |
|-------|-------------|----------|----------------------|
| **Público** | Aprobado para divulgación pública | Sitio de marketing, repos OSS, ofertas | Sin control de acceso; backups estándar |
| **Interno** | Solo empleados y contratistas | Wikis, planes, métricas no sensibles | Acceso por roles; cifrado en reposo; MFA remoto |
| **Confidencial** | La divulgación daña a la empresa | PII de clientes, finanzas, código fuente | Cifrar reposo+tránsito; mínimo privilegio; auditoría |
| **Restringido** | La divulgación causa daño severo | Tarjetas, SSNs, salud, claves | Cifrar reposo+tránsito; necesidad de saber; auditoría estricta |

## 2. Inventario de Datasets

| Dataset | Clasificación | Almacén | Cifrado | Control de Acceso | Retención | Responsable |
|---------|---------------|---------|---------|-------------------|-----------|-------------|
| `user_profiles` | Confidencial | PostgreSQL RDS | AES-256 | RBAC: ing, soporte | 7 años post-baja | @data-owner |
| `payment_tokens` | Restringido | Vault / HSM | AES-256-GCM | Solo equipo de pagos | 90 días | @security-owner |
| `public_docs` | Público | S3 (público) | Ninguno | Ninguno | Indefinido | @content-owner |

## 3. Reglas de Manejo por Nivel

### Acceso

| Nivel | Autenticación | Autorización | MFA | Acceso Remoto |
|-------|---------------|--------------|-----|---------------|
| Público | Ninguna | Ninguna | N/A | Abierto |
| Interno | SSO | Por roles | Requerido | VPN + MFA |
| Confidencial | SSO | Rol + aprobación | Requerido | VPN + MFA + justificación |
| Restringido | SSO + llave hardware | Necesidad de saber + multi-parte | Requerido | VPN dedicada + justificación |

### Transmisión

| Nivel | Red Interna | Red Externa | Email / Chat |
|-------|-------------|-------------|--------------|
| Público | Sin cifrar | Sin cifrar | Permitido |
| Interno | TLS 1.2+ | TLS 1.2+ | Permitido con cuidado |
| Confidencial | TLS 1.2+ | TLS 1.2+ + escaneo DLP | Solo canales aprobados |
| Restringido | TLS 1.2+ + mTLS | Prohibido — transferencia segura | Prohibido — intercambio aprobado |

### Almacenamiento

| Nivel | Cifrado en Reposo | Gestión de Claves | Backup | Geolocalización |
|-------|-------------------|-------------------|--------|-----------------|
| Público | Opcional | Estándar | Estándar | Cualquier región |
| Interno | AES-256 | Estándar | AES-256 | Regiones aprobadas |
| Confidencial | AES-256 | HSM o KMS | AES-256 | Regiones aprobadas + residencia |
| Restringido | AES-256-GCM | HSM | AES-256 + air-gapped | Regiones aprobadas, sin cruce de fronteras |

## 4. Registro de Excepciones

| Dataset | Nivel Menor Solicitado | Justificación | Riesgo Aceptado Por | Fecha | Fecha de Revisión |
|---------|------------------------|---------------|---------------------|-------|-------------------|
| | | | | | |

Fin del documento. Revisar y actualizar trimestralmente.

Explicación

La plantilla reemplaza términos vagos como “sensible” con cuatro niveles concretos. Cada nivel lleva reglas explícitas de manejo para acceso, transmisión y almacenamiento, de modo que un ingeniero que lee “Confidencial” sabe exactamente qué controles aplican — no hay espacio para la interpretación. El inventario de datasets te obliga a catalogar lo que tienes antes de poder protegerlo; la mayoría de los equipos descubre en este paso datasets que no sabían que existían. El registro de excepciones reconoce que las necesidades de negocio a veces exigen flexibilizar las reglas, pero solo con aceptación de riesgo documentada y una fecha de revisión, para que las excepciones caduquen en vez de convertirse en agujeros permanentes y silenciosos.

Mantén el número de niveles bajo. Los esquemas de seis o más niveles parecen exhaustivos sobre el papel pero colapsan en la práctica porque nadie distingue entre “Nivel 4” y “Nivel 5” a las 2 AM durante un incidente. Cuatro niveles mapean limpiamente a las decisiones que los ingenieros toman de verdad: ¿puedo poner esto en un ticket público? ¿Puedo enviarlo por email? ¿Necesita un flujo de aprobación?

Árbol de Decisión de Clasificación de Datos

Cuando aparece un dataset nuevo y el responsable no sabe qué etiqueta aplicar, recorre este árbol:

El árbol termina a propósito cada camino ambiguo en Confidencial en lugar de en una etiqueta “pendiente”. Un dataset que pasa semanas sin clasificar es un dataset sin reglas de manejo — lo que en la práctica significa Público por accidente.

Requisitos de Manejo por Clasificación

Esta matriz resume los controles que dispara cada nivel. Es la parte del documento que los auditores piden primero, y la que los ingenieros pegan en los README de sus servicios.

Clasificación	Cifrado	Acceso	Logging	Retención
Público	No requerido	Cualquiera	Opcional	Sin restricción
Interno	En reposo	Empleados	Requerido	Según política
Confidencial	Reposo + tránsito	Solo necesidad de saber	Requerido + trazabilidad	Según política + retención legal
Restringido	Reposo + tránsito + key vault	Solo individuos nombrados	Requerido + logs a prueba de manipulación	Según política + retención legal + derecho al olvido

Cómo Implantarlo

Un esquema de clasificación que solo vive en una página de wiki no cambia nada. Los pasos de abajo asumen una organización de ingeniería de tamaño medio; un equipo pequeño puede comprimir los pasos 1–3 en un solo taller de una tarde. Despliégalo en este orden:

1. Primero inventario, después clasificación. Exporta la lista de tus almacenes de datos (RDS, S3, warehouses, herramientas SaaS) y asigna un responsable a cada dataset antes de debatir niveles. Los datasets sin responsable se marcan, no se clasifican — un dataset sin dueño ya es un hallazgo en sí mismo.
2. Clasifica en la creación, no retroactivamente. Añade un campo “clasificación de datos” a tu checklist de onboarding de servicios, a la plantilla de PR o a las variables de tus módulos Terraform. La clasificación retroactiva de 200 datasets existentes lleva trimestres; etiquetar el próximo dataset lleva un minuto.
3. Conecta la aplicación donde fluyen los datos. Las etiquetas solo sirven si algo las comprueba: reglas DLP en email y almacenamiento, políticas de bucket que bloquean ACLs públicos en datasets no Públicos, checks de CI que fallan cuando un esquema gana una columna PII sin etiqueta.
4. Maneja los datasets mixtos al nivel más alto. Una hoja de cálculo con copia de marketing Pública y números de tarjeta Restringidos es Restringida. Cuando sea posible, separa el dataset para que el grueso no suba de nivel por culpa de unas pocas columnas.
5. Revisa con calendario y con disparadores. Trimestral para Restringido, semestral para Confidencial, anual para Interno y Público. Revisa también cuando cambia el propósito de un dataset, empieza a aplicar una regulación, o dos datasets se fusionan.
6. Trata los datos de test y staging como clasificados. Los clones de producción en staging llevan la misma sensibilidad. O los anonimizas a una clasificación menor o aplicas los mismos controles — “es solo staging” es como empiezan la mayoría de las filtraciones en entornos de prueba.
7. Alimenta las etiquetas al resto de tus documentos de seguridad. La clasificación es un input, no un producto: las reglas de retención de tu política de retención de datos, los pasos de contención de tu playbook de respuesta a incidentes y el alcance de tu checklist de auditoría de seguridad la leen. Cuando esos documentos discrepen con el esquema, corrige el esquema — no bifurques el vocabulario.

Ejemplo Resuelto

Un SaaS B2B pequeño (“Acme Analytics”) adopta la plantilla. Su inventario completado queda así:

Dataset	Nivel	Razonamiento
customers.user_profiles	Confidencial	Nombres, emails, empresa — PII, pero no categorías sensibles
billing.payment_tokens	Restringido	Datos de tarjeta vía tokens del PSP; aplica ámbito PCI
analytics.events	Interno	Métricas de uso de producto, agregadas, sin PII tras filtrado
logs.app_requests	Confidencial	Contiene IDs de usuario y rutas; a menudo olvidado
db_backups.nightly	Restringido	El volcado completo incluye perfiles y tokens — gana el nivel más alto
blog.content	Público	Material de marketing aprobado
sales.pipeline_export	Confidencial	Emails de prospectos y valores de tratos; solo dirección comercial

Tres decisiones no fueron obvias y merecen documentarse: el almacén de logs subió de Interno a Confidencial porque lleva IDs de usuario; los backups de base de datos heredaron el nivel más alto presente (Restringido), lo que los obligó a moverse a almacenamiento cifrado por necesidad de saber en lugar del bucket de backups compartido; y el pipeline de analítica necesitó un filtro documentado que demuestra que elimina PII antes de que los eventos lleguen al warehouse Interno. Ese filtro es ahora una entrada del registro de excepciones con revisión trimestral.

Noventa días después, el esquema ya había compensado el esfuerzo: dos excepciones caducaron en lugar de pudrirse, y el equipo de pagos movió el manejo de tarjetas a los hosted fields de su PSP, lo que les permitió bajar el ámbito de billing de Restringido a Confidencial y reducir a la mitad la superficie de auditoría.

Variantes

Contexto	Niveles Extra	Diferencia Clave
Salud (HIPAA)	Agregar etiquetas PHI / ePHI	Datos de pacientes siempre son Restringidos; BAAs requeridos
Finanzas (PCI DSS)	Agregar CDE (Cardholder Data Environment)	Datos de tarjetas son Restringidos; segmentación de red obligatoria
Gobierno	Agregar Unclassified, CUI, Secret, Top Secret	Acceso basado en autorización; air-gapping común
Startup SaaS	Fusionar Interno + Confidencial	Simplicidad sobre completitud cuando el equipo es pequeño
Operaciones UE	Agregar marca “Datos Personales UE”	Residencia GDPR y acuerdos de procesamiento requeridos

Elige primero el esquema base y solo añade etiquetas cuando una regulación lo exija. Un esquema de cinco niveles donde el quinto cubre tres datasets suele expresarse mejor como Restringido + una marca, como en la fila de la UE.

Lo Que Funciona

1. Etiqueta los datos en la creación, no en el almacenamiento; la clasificación retroactiva es cara y propensa a errores
2. Automatiza la clasificación donde sea posible; las herramientas DLP pueden etiquetar datos según patrones (tarjetas de crédito, SSNs)
3. Revisa las clasificaciones trimestralmente; un dataset “público” que se vuelve crítico para ingresos puede necesitar subir de nivel
4. Entrena a los ingenieros en la diferencia entre Confidencial y Restringido; esa brecha es donde ocurren las filtraciones
5. Registra cada excepción; los patrones de excepciones indican desalineación de política o falta de formación

Errores Comunes

1. Clasificar todo como Confidencial para estar “seguros”; diluye la protección y frena a la ingeniería
2. No etiquetar datos de test/staging; los desarrolladores clonan producción y olvidan que los datos siguen siendo sensibles
3. Ignorar los metadatos; un archivo de log con IDs de usuario es Confidencial aunque no contenga nombres
4. No incluir a los proveedores terceros en las reglas; una herramienta SaaS con SSO sigue siendo externa
5. Tratar la clasificación como una auditoría única; los datos cambian, los servicios evolucionan y las clasificaciones se degradan
6. Clasificar el origen pero no las copias; un CSV exportado de una tabla Restringida en la bandeja de marketing sigue siendo Restringido

Solución de Problemas

• Los equipos no se ponen de acuerdo en un nivel: usa el árbol de decisión, y si sigue siendo ambiguo, clasifica más alto y registra el debate en el registro de excepciones para la próxima revisión.
• La herramienta DLP inunda de falsos positivos: ajusta los patrones contra muestras reales de tus datos antes de activar el modo bloqueo; una herramienta que da la voz de alarma en falso acaba siendo ignorada.
• Los datos legacy no están etiquetados y nadie los posee: asigna un responsable provisional (normalmente el equipo que más los lee) y clasifica al nivel más alto que el contenido pueda tener hasta que alguien demuestre lo contrario.
• Un proveedor no firma el DPA que exige tu nivel Restringido: mantén a ese proveedor fuera del flujo de datos Restringidos por completo — una excepción “temporal” sin fecha de revisión es permanente.
• Las etiquetas existen pero nada las aplica: elige un punto de aplicación que duela (normalmente el check de bucket público o la regla DLP de email) y hazlo real antes de añadir más papeleo.

Lectura Adicional

• ISO/IEC 27001 — Gestión de seguridad de la información: el control 5.12 del Anexo A cubre la clasificación de la información; la base que la mayoría de los auditores espera.
• NIST SP 800-60: guía del gobierno de EE. UU. para mapear tipos de información a categorías de seguridad.
• Documentación de AWS Macie: descubrimiento y clasificación gestionados de datos sensibles en S3.
• Google Cloud Sensitive Data Protection: escaneo DLP gestionado para almacenamiento y warehouses en GCP.
• Microsoft Purview: clasificación y gobernanza de datos en Microsoft y entornos multi-cloud.
• Texto del GDPR europeo (EUR-Lex): los artículos 5, 30 y 32 impulsan los registros de tratamiento y requisitos de seguridad detrás de la mayoría de los esquemas de clasificación.

Archivos complementarios: el repo companion de data-classification-template tiene la plantilla rellenable y el ejemplo completado para un SaaS B2B de esta página.