Compliance

Cumplimiento, gobernanza y auditoría

Resumen

El cumplimiento consiste en demostrar que una organización opera según requisitos internos y externos. No es lo mismo que seguridad: un sistema puede cumplir una lista de controles y seguir siendo vulnerable, o ser razonablemente seguro y carecer de evidencia. Esta guía de estudio independiente, no afiliada a la Linux Foundation, explica cómo se relacionan marcos, normas, leyes y auditorías.

Se presentan NIST CSF, ISO/IEC 27001, SOC 2, GDPR y CIS Controls como referencias distintas, no sinónimos. El objetivo es interpretar alcance, evidencia y límites.

Objetivos de aprendizaje

Al terminar este tema deberías poder:

• Distinguir marco, norma, ley, certificación y atestación.
• Explicar gobernanza y registro de riesgos.
• Describir qué evalúan ISO/IEC 27001 y SOC 2.
• Reconocer principios y roles del GDPR.
• Relacionar CIS Controls con evidencia operativa.
• Interpretar alcance y límites de una auditoría.

Prerrequisitos y conexiones

Requiere security-basics para controles, identidad y riesgo, y sensitive-data para clasificación, cifrado y retención. Se relaciona con best-practices por documentación y actualización, con cloud-best-practices por responsabilidad compartida y con disaster-recovery por continuidad. También conecta con open-source-licensing cuando el cumplimiento incluye obligaciones de licencias.

Marco, norma, ley y atestación

Un marco organiza buenas prácticas y vocabulario; su adopción suele ser voluntaria. El NIST Cybersecurity Framework es un ejemplo: ayuda a estructurar funciones como Gobernar, Identificar, Proteger, Detectar, Responder y Recuperar, pero no impone por sí mismo obligaciones legales.

Una norma establece requisitos verificables y puede ser certificable. ISO/IEC 27001 especifica requisitos para un sistema de gestión de seguridad de la información. Una ley o reglamento es obligatorio en su ámbito; el GDPR regula el tratamiento de datos personales en la Unión Europea y tiene alcance extraterritorial en supuestos definidos.

Una certificación la emite un organismo independiente tras auditar conformidad. Una atestación es una opinión profesional sobre controles o información; un informe SOC 2 es una atestación, no una certificación. Confundir estas categorías lleva a prometer garantías que el documento no ofrece.

Gobernanza, riesgo y evidencia

La gobernanza define quién decide y cómo se rinde cuentas. Incluye políticas, roles, comités, presupuesto y un proceso para aceptar riesgos residuales. Sin gobernanza, los controles se convierten en tareas aisladas que nadie mantiene.

El registro de riesgos relaciona activos, amenazas, probabilidad, impacto y tratamiento. Un control mitiga un riesgo concreto; sin esa relación, la evidencia se vuelve burocrática. La dirección debe definir apetito de riesgo y aprobar excepciones con fecha de revisión, en lugar de tolerar desviaciones invisibles.

La evidencia demuestra que un control funcionó durante el periodo auditado. Sirve un ticket de cambio con aprobación, un registro de acceso, una captura con fecha y sistema de origen, o el resultado de una revisión periódica. Una política sin aplicación demostrable es una intención, no un control operativo.

ISO/IEC 27001 y SOC 2

ISO/IEC 27001 adopta un enfoque de sistema de gestión. La organización define el alcance, identifica riesgos, selecciona controles del Anexo A y mantiene un ciclo de mejora continua. La certificación evalúa el sistema dentro de ese alcance, no cada aplicación ni empleado. Un certificado indica que el sistema fue auditado en un periodo y alcance concretos; no demuestra ausencia de incidentes.

SOC 2 se basa en los criterios de servicios de confianza de AICPA. La seguridad es el criterio común; según el informe pueden cubrirse disponibilidad, integridad del procesamiento, confidencialidad y privacidad. Un Tipo I evalúa el diseño en una fecha; un Tipo II, su eficacia operativa durante un periodo. El informe suele tener destinatarios restringidos y no equivale a una certificación pública.

Ambos enfoques se complementan: ISO/IEC 27001 aporta un sistema de gestión y SOC 2 una opinión sobre controles de servicio. Ninguno sustituye pruebas técnicas, gestión de vulnerabilidades ni respuesta a incidentes.

GDPR y protección de datos

El GDPR exige licitud, lealtad y transparencia; limitar la finalidad; minimizar los datos; garantizar exactitud; limitar la conservación; asegurar integridad y confidencialidad; y demostrar responsabilidad. El consentimiento es una base jurídica posible, pero no la única ni siempre la adecuada.

El responsable decide finalidades y medios; el encargado trata datos por cuenta del responsable y sigue sus instrucciones. Un proveedor SaaS suele actuar como encargado respecto de los datos de sus clientes, aunque puede ser responsable de otros tratamientos. Los titulares tienen derechos de acceso, rectificación, supresión, limitación, portabilidad y oposición, con matices.

Las violaciones deben notificarse a la autoridad de control sin dilación indebida y, cuando sea factible, dentro de las 72 horas siguientes al conocimiento, salvo que no sea probable un riesgo. También pueden exigir comunicación a los interesados. Estas obligaciones dependen del contexto y requieren análisis jurídico; esta guía no sustituye asesoramiento legal.

CIS Controls y auditoría práctica

Los CIS Controls son un conjunto priorizado de salvaguardas técnicas y operativas. Se organizan en controles e implementaciones, con grupos de implementación (IG1, IG2, IG3) según el perfil de riesgo. Su valor está en la especificidad: inventario de activos, gestión de vulnerabilidades, control de acceso, registros y respaldo.

Una auditoría introductoria suele revisar alcance, políticas, entrevistas, configuraciones y muestras de evidencia. El auditor selecciona muestras y evalúa si el control está diseñado y opera. Por eso una auditoría aporta confianza razonable, no certeza absoluta.

El mapeo entre marcos debe documentar versión, alcance y criterio de correspondencia. Un control de CIS puede contribuir a varios objetivos de NIST o ISO, y puede haber requisitos sin cobertura equivalente. La trazabilidad entre requisito, control, evidencia y responsable hace defendible el cumplimiento y facilita la mejora.

Ciclo de una auditoría: preparación, campo y cierre

Una auditoría tiene fases reconocibles. En la preparación se fija el alcance, se identifican los requisitos aplicables, se solicita la documentación inicial y se acuerda el calendario con los responsables. En el trabajo de campo se entrevista a los dueños de proceso, se inspeccionan configuraciones y se prueban muestras. En el cierre se discuten los hallazgos, se clasifican por severidad y se emite el informe con recomendaciones y plazos.

La selección de muestras busca representatividad, no exhaustividad. Un auditor puede revisar veinte altas de usuario de un trimestre y concluir sobre el proceso si la muestra se eligió sin sesgo; si los tickets se ordenaron por conveniencia, la conclusión pierde valor. Por eso conviene conservar la población completa de la que se extrajo la muestra y el criterio aplicado, de modo que otra persona pueda repetir la selección.

Un hallazgo describe la condición observada, el criterio incumplido, el riesgo asociado y la recomendación. Distinguir una observación de mejora de un incumplimiento evita alarmismo: no toda sugerencia implica una brecha. Las respuestas del auditado y los planes de acción con responsable y fecha cierran el ciclo, y su seguimiento en la auditoría siguiente demuestra que el sistema aprende en lugar de repetir la misma debilidad.

Tipo de revisión	Quién la realiza	Resultado	Uso habitual
Auditoría interna	función independiente de la organización	informe interno y plan de acción	control de gestión y preparación
Certificación	organismo de certificación acreditado	certificado con alcance y vigencia	prueba frente a terceros
Atestación	firma de auditoría independiente	informe con opinión y periodo	confianza para clientes
Inspección regulatoria	autoridad competente	requerimientos o sanción	verificación legal

Antes de una certificación resulta útil una revisión de brechas que compare el estado real con los requisitos y priorice lo pendiente. Documentar el alcance en un diagrama de sistemas y flujos permite que auditor y auditado hablen de lo mismo. También conviene ensayar la obtención de evidencia: si un control existe pero su prueba tarda semanas en reunirse, el equipo llegará al campo con retraso y con huecos.

Proveedores, subencargados y cadena de suministro

El cumplimiento no termina en el perímetro propio. Un proveedor que trata datos personales por cuenta de la organización actúa como encargado y debe estar sujeto a un contrato con instrucciones documentadas, medidas de seguridad, autorización de subencargados, asistencia al responsable y devolución o supresión al terminar el servicio. La responsabilidad frente al titular y la autoridad no se transfiere por contratar a un tercero.

La debida diligencia previa debería revisar el alcance del servicio, los datos implicados, las certificaciones y atestaciones vigentes, la historia de incidentes y la capacidad de notificar brechas en plazo. Un certificado del proveedor es un insumo, no una garantía sobre el servicio concreto que se contrata: hay que comprobar que su alcance cubre la función utilizada y que la fecha sigue vigente.

El inventario de proveedores permite ver concentración de riesgo, dependencias de cuarto nivel y servicios sin contrato actualizado. La revisión periódica no consiste solo en pedir el mismo PDF cada año; incluye verificar cambios de subencargados, modificaciones de arquitectura y resultados de pruebas. En la salida del proveedor, el plan de transición debe prever la exportación de datos en formato utilizable, la eliminación verificable de copias y la revocación de accesos que ya no correspondan.

Monitoreo continuo y métricas de cumplimiento

Una auditoría fotografían un periodo, mientras que la operación cambia a diario. El monitoreo continuo convierte el cumplimiento en un proceso observable: controles con dueño, evidencia generada de forma recurrente y umbrales que disparan revisión. Sin esa rutina, el equipo reconstruye el año entero en las semanas previas a la auditoría y descubre tarde las excepciones.

Métricas útiles describen la cobertura y la oportunidad de los controles: porcentaje de activos inventariados, tiempo desde la publicación de un parche crítico hasta su aplicación, revisiones de acceso completadas, tiempo medio para revocar una cuenta, copias restauradas con éxito, antigüedad de hallazgos críticos abiertos y proveedores con evaluación vigente. Son más informativas que contar políticas publicadas o sesiones de formación impartidas, que miden actividad y no efecto.

Cada métrica necesita una definición estable, una fuente de datos y un responsable de interpretarla. Un panel sin umbrales se convierte en decoración; con umbrales, obliga a decidir qué hacer cuando el indicador se degrada. La evidencia automatizada reduce el esfuerzo de recolección, pero no demuestra por sí sola que el control funcione: alguien debe revisar excepciones y confirmar que el resultado corresponde a la realidad operativa.

Documentación, versionado y retención de evidencia

Las políticas siguen un ciclo de vida: borrador, aprobación, publicación, revisión y retiro. Cada documento debería tener dueño, fecha de vigencia, historial de cambios y una ubicación única como fuente de verdad. Las copias sueltas en unidades compartidas o en correos antiguos hacen que dos equipos sigan versiones distintas y que la auditoría encuentre contradicciones difíciles de explicar.

La evidencia debe conservar contexto: qué control demuestra, qué sistema la produjo, el periodo cubierto y quién la extrajo. Una captura sin fecha ni origen pierde fuerza; un registro exportado con marca temporal y control de integridad se defiende mejor. Para pruebas sensibles conviene limitar quién accede y mantener una cadena de custodia que registre transferencias y consultas.

El plazo de conservación se alinea con obligaciones legales, compromisos contractuales y necesidades de auditoría, y se documenta en la política de retención. Guardar todo indefinidamente aumenta la exposición y el coste; borrar demasiado pronto deja sin sustento una revisión posterior. Cuando el periodo termina, la eliminación debe ser verificable y coherente con la retención de los datos originales que la evidencia describe.

Privacidad desde el diseño y evaluación de impacto

El GDPR exige proteger los datos desde el diseño y por defecto: aplicar medidas técnicas y organizativas antes de iniciar el tratamiento y configurar por defecto la mínima recogida, el menor acceso y la retención más corta compatible con la finalidad. Llevarlo a la práctica significa incluir requisitos de privacidad en el ciclo de desarrollo, revisar flujos de datos en el diseño de una función y no esperar al lanzamiento para preguntar qué información se recoge.

Cuando un tratamiento puede entrañar un alto riesgo para los derechos de las personas, procede una evaluación de impacto. El análisis describe el tratamiento y su necesidad, evalúa los riesgos y define medidas para mitigarlos; según el resultado puede requerir consulta previa a la autoridad de control. La evaluación no es un formulario aislado: se actualiza cuando cambia la tecnología, la escala o la finalidad.

El registro de actividades de tratamiento y la figura del delegado de protección de datos apoyan esta disciplina cuando resultan aplicables. En términos operativos, conviene mantener diagramas de flujo, inventario de categorías de datos, base jurídica por finalidad y pruebas de que las medidas declaradas están desplegadas. La documentación debe reflejar lo que ocurre, no lo que se deseaba al iniciar el proyecto.

Código abierto, licencias y cadena de componentes

El software de terceros introduce obligaciones que conviven con los controles de seguridad. Las licencias permisivas suelen exigir atribución y avisos; las de tipo copyleft pueden imponer condiciones sobre la distribución del código derivado. La obligación concreta depende de cómo se combina y distribuye el componente, por lo que el análisis debe hacerse por producto y no solo por repositorio.

Un inventario de componentes y un formato de lista de materiales de software facilitan saber qué se usa y qué versión. Formatos como SPDX o CycloneDX permiten intercambiar esa información y enlazarla con vulnerabilidades conocidas. El escaneo en integración continua detecta licencias incompatibles y dependencias desactualizadas antes de la entrega, mientras que la revisión periódica cubre componentes que ya están en producción.

El cumplimiento de licencias y el de seguridad comparten disciplina: ambos necesitan alcance, evidencia y un responsable que revise excepciones. Documentar la aprobación de una excepción, su justificación y su fecha de revisión evita que una decisión puntual se convierta en práctica permanente sin que nadie lo note.

Función de auditoría interna y seguimiento

La auditoría interna aporta una mirada independiente de la gestión. Para que esa independencia sea real, la función no debería reportar al mismo responsable cuyos controles evalúa, sino a la dirección o al comité de auditoría. Su plan anual se construye por riesgo, combina revisiones programadas con investigaciones puntuales y prioriza procesos con mayor impacto o con cambios recientes.

El seguimiento de hallazgos es donde se gana o se pierde el valor de la auditoría. Cada hallazgo necesita dueño, acción concreta, fecha comprometida y criterio de cierre verificable. Un cierre no es una promesa de que ya se corrigió, sino evidencia de que la causa se trató y de que el control opera. Revisar los vencidos con la dirección convierte la lista en una herramienta de gestión y no en un archivo olvidado.

La función también puede asesorar sobre el diseño de controles, siempre que no audite después lo que ayudó a construir sin declarar esa participación. Esa separación protege la objetividad del informe y la credibilidad ante un tercero que lea la conclusión.

Excepciones y riesgos aceptados

No todo requisito se cumple de inmediato. Una excepción formal registra qué control no se aplica, por qué, qué riesgo se asume, quién lo aprueba y hasta cuándo. Sin ese registro, la desviación se vuelve invisible y la auditoría la descubre como un incumplimiento no gestionado.

Las excepciones deben tener fecha de caducidad y un plan para volver al estado conforme. Acumular excepciones sin revisión equivale a redefinir el estándar por la puerta de atrás. La dirección acepta el riesgo residual con información suficiente; el equipo técnico no debería asumirlo en silencio.

El inventario de excepciones se revisa en el mismo ciclo que el registro de riesgos, de modo que ambos documentos cuenten la misma historia y que una excepción vencida no siga justificando una práctica que ya nadie defiende.

Ejemplos prácticos

SaaS que busca SOC 2 Tipo II. Define el servicio y el periodo, documenta controles de acceso, cambios, respaldo y monitoreo, y conserva evidencia. El auditor evalúa la eficacia operativa, no solo las políticas.

Certificación ISO/IEC 27001. La organización delimita qué sedes, sistemas y servicios entran en el alcance, realiza evaluación de riesgos y trata los hallazgos. Un alcance demasiado amplio vuelve inmanejable la auditoría; uno demasiado estrecho puede excluir el servicio que el cliente necesita evaluar.

Solicitud de un titular. Un cliente pide acceso a sus datos personales. El equipo verifica identidad, localiza la información en sistemas y copias, responde dentro del procedimiento y registra la solicitud. La respuesta debe ser comprensible y no revelar datos de terceros.

Errores frecuentes

• Llamar "certificación" a un informe SOC 2.
• Suponer que un certificado ISO/IEC 27001 garantiza que no habrá incidentes.
• Copiar políticas sin adaptarlas al alcance ni a los riesgos reales.
• Tratar la auditoría como un evento anual y no como monitoreo continuo.
• Declarar cumplimiento sin evidencia verificable.
• Asumir que el consentimiento es siempre la base jurídica adecuada.
• Confundir responsable y encargado del tratamiento.
• Ampliar el alcance para "incluir todo" y perder capacidad de gestión.

Puntos clave para el examen

Distingue marco voluntario, norma certificable, ley obligatoria y atestación. NIST CSF organiza funciones; ISO/IEC 27001 exige un sistema de gestión; SOC 2 opina sobre controles de servicio; GDPR regula datos personales; CIS Controls prioriza salvaguardas. La evidencia y el alcance determinan el valor de una auditoría. Cumplimiento no equivale a seguridad.

Recursos externos

• NIST Cybersecurity Framework
• ISO/IEC 27001
• AICPA: SOC 2
• Reglamento General de Protección de Datos (GDPR)
• CIS Controls

Autoevaluación

1. ¿Un informe SOC 2 es una certificación? Respuesta: No; es una atestación. Justificación: Un auditor independiente opina sobre controles según criterios de confianza; no acredita el sistema como certificación.

2. ¿Qué evalúa un SOC 2 Tipo II frente a un Tipo I? Respuesta: El Tipo II evalúa la eficacia operativa durante un periodo; el Tipo I, el diseño en una fecha. Justificación: Un control puede estar bien diseñado y no funcionar de forma sostenida.

3. ¿Qué distingue a un encargado del tratamiento? Respuesta: Trata datos personales por cuenta del responsable y siguiendo sus instrucciones. Justificación: El responsable decide finalidades y medios; el encargado no adquiere la propiedad de los datos.

4. ¿Qué aporta el alcance en una auditoría ISO/IEC 27001? Respuesta: Delimita qué sistemas, sedes y servicios cubre el certificado. Justificación: Un certificado no evalúa toda la organización si el alcance excluye partes; el cliente debe comprobar que cubre su servicio.

5. ¿Por qué una auditoría no garantiza seguridad absoluta? Respuesta: Porque evalúa controles y muestras en un periodo, no todas las operaciones ni todos los ataques. Justificación: El riesgo residual persiste; aporta confianza razonable y debe complementarse con pruebas técnicas y monitoreo.