¿Cómo hago esto sin romper un control?

Registra los eventos relevantes para la seguridad (quién hizo qué y cuándo), incluye siempre al actor, escríbelos en un lugar duradero y no permitas que una limpieza posterior los elimine. SOC 2 (CC7.2) e ISO 27001 (A.8.15) exigen esto y lo verifican mediante muestreo de los eventos que realmente registraste.

Nunca coloques la clave en el código fuente. Léela desde variables de entorno o un almacén de secretos gestionado en tiempo de ejecución, manténla fuera del repositorio y los registros, y rota cualquier secreto que se haya confirmado alguna vez. ISO 27001 A.8.24 (y el simple sentido común) exige que las claves se gestionen, no se codifiquen.

Asegúrate de que la ruta de eliminación llegue a todos los lugares donde residen los datos de la persona: la base de datos principal, cachés, índices de búsqueda, analíticas, copias de seguridad (con su propio ciclo de vida documentado) y cualquier procesador de terceros al que hayas enviado los datos. Cuando aplica el derecho al olvido (GDPR Art. 17), una copia olvidada es lo que lo invalida, por lo que la ruta de eliminación debe llegar a todas.

Fija la versión, verifica lo que descargas (un archivo lock y comprobación de integridad), evita ejecutar scripts de instalación remotos y prefiere tu registro verificado o espejo. NIS 2 (Art. 21(2)(d)) trata tus dependencias como parte de la seguridad de la cadena de suministro, y los controles sobre ellas residen en tu manifiesto y proceso de construcción.

Activa el cifrado en reposo para cada almacenamiento que contenga información de salud protegida electrónicamente (la base de datos, buckets, volúmenes, copias de seguridad) o documenta por qué existe una salvaguarda equivalente. La especificación de cifrado de HIPAA (164.312(a)(2)(iv)) es abordable: impleméntala cuando sea razonable o registra una alternativa equivalente, en lugar de omitirla.

Otorga solo el acceso que cada rol o servicio necesita, niega por defecto y evita comodines. SOC 2 (CC6.1) verifica el acceso lógico, y el mínimo privilegio es lo que un auditor revisa: ¿puede cada identidad realizar solo lo que su función requiere, y nada más?

Registra referencias y códigos mínimos, no contenidos completos. Graba un id de solicitud o un id de pedido, oculta los campos personales antes de que se escriba nada y nunca registres todo el objeto de solicitud o usuario. Registrar menos datos, y menos datos identificables, es en lo que consiste la minimización de datos del GDPR (Art. 5(1)(c)). Trata un identificador que apunte a una persona como dato personal también, y limítate a lo que realmente necesitas para investigar.

Valide el destino antes de obtenerlo: exija https, resuelva el host y rechace direcciones privadas, internas y de enlace local (incluyendo los extremos de metadatos en la nube). Prefiera una lista de permitidos cuando los destinos sean conocidos, y no siga redirecciones ciegamente. La falsificación de solicitudes del lado del servidor es un problema de validación de entrada (NIST 800-53 SI-10), y la verificación debe estar en el código que realiza la solicitud.

Una exportación es una nueva copia de datos personales, así que trátala como tal: asígnale un plazo de caducidad para que no supere su finalidad, exporta solo los campos y filas necesarios para el propósito y evita que una exportación recurrente se convierta en un segundo almacenamiento permanente y no regulado. Eso es lo que establece el principio de limitación del almacenamiento del GDPR (Art. 5(1)(e)).

Usa la tokenización de tu procesador de pagos para que los datos de la tarjeta se envíen directamente a ellos, no a través de tus servidores. Almacena el token que devuelven y los últimos cuatro dígitos para mostrar, y nunca guardes el número completo de la tarjeta ni el código de verificación. Así cumples con el Requisito 3 de PCI DSS y reduces el alcance de PCI que te aplica.

Si una decisión sobre una persona se toma únicamente mediante un algoritmo y tiene efectos legales o de similar relevancia para ella (denegar un reembolso, un préstamo, una cuenta), el GDPR Art. 22 la restringe: como regla general, la persona tiene derecho a no estar sujeta a una decisión exclusivamente automatizada de ese tipo. Cuando esta decisión esté permitida de todos modos (por ejemplo, porque es necesaria para un contrato o se basa en el consentimiento explícito de la persona), el Art. 22(3) exige salvaguardas, como la posibilidad de obtener intervención humana, expresar una opinión y impugnar el resultado. En cualquier caso, no dejes que la rama automatizada sea la última palabra: redirige estas decisiones a una ruta donde una persona pueda revisarlas.

Restringir quién puede acceder a funciones sensibles es el objetivo de SOC 2 CC6.1 (controles de acceso lógico), y para acciones privilegiadas una sesión válida suele no ser suficiente por sí sola. Exige un segundo factor en el momento de la acción privilegiada, deniega por defecto si falta y registra la verificación, de modo que acceder a una ruta de administrador requiera más que una sesión robada o persistente.

Hoy en día, tres tipos de revisores automatizados analizan una pull request: revisores de código que buscan defectos, revisores de seguridad que buscan vulnerabilidades y revisores de cumplimiento que evalúan el cambio frente a los marcos normativos que tu empresa debe cumplir. heygrc es un revisor de cumplimiento para pull requests: revisa cada PR frente a los marcos que seleccionas y cita el control específico que un cambio afecta, por ejemplo ISO 27001 A.8.15 o SOC 2 CC6.1. Hasta donde sabemos, es el primer revisor de cumplimiento para pull requests (julio de 2026).

La mayoría de las plataformas GRC y de automatización de cumplimiento se integran con GitHub a nivel de cuenta y repositorio: leen configuraciones como la protección de ramas y las revisiones obligatorias como evidencia de que tu control de gestión de cambios funciona. Esa integración lee configuración, no código. Revisar la pull request en sí, leer las líneas modificadas y nombrar el control que ponen en riesgo, es un trabajo distinto. heygrc realiza ese trabajo: una aplicación de GitHub que revisa cada pull request frente a los marcos seleccionados y publica el hallazgo como una verificación en la PR.

Una auditoría es un indicador rezagado: muestrear lo que se implementó meses atrás, cuando la violación ya está en producción y es costosa. La revisión de código es el indicador adelantado, el último momento en que una violación está a un clic de no existir. Para detectarla allí: identifica qué controles realmente residen en el código, incluye la pregunta de cumplimiento al revisar cada diff, fundamenta cada bandera en la cláusula específica y conserva el rastro para que la revisión misma se convierta en evidencia de auditoría.

Revisa el código generado por IA con el mismo estándar que el código humano: el auditor no preguntará quién escribió un cambio, solo si el control funcionó. Lo que cambia con los agentes es el volumen y el patrón de fallos. Un agente optimiza para la tarea visible, por lo que el código de control que parece fricción (una línea de registro, una verificación de permisos, un límite de retención) está en riesgo en sus difs, y los agentes abren más solicitudes de extracción de las que un revisor humano puede manejar. Automatiza la primera pasada; reserva a los humanos para las decisiones de juicio.

Sí. heygrc es una GitHub App que revisa cada pull request frente a ISO 27001:2022 y cita el control específico del Anexo A que afecta un cambio, por ejemplo A.8.15 para un registro de auditoría silenciado o A.8.24 para criptografía debilitada. La instalas en tus repositorios, seleccionas ISO 27001 y cualquier otro marco aplicable, y publica los hallazgos como comentarios de revisión más un estado de verificación que no bloquea la fusión a menos que lo requieras. Hasta donde sabemos, es el primer revisor de cumplimiento para pull requests (julio de 2026).

Solo si lo deseas. Un chequeo de cumplimiento en una pull request debe predeterminarse como un estado neutral: publica hallazgos y un estado de chequeo, y la decisión de fusión sigue siendo del ingeniero. Los equipos que quieren control estricto pueden exigir el chequeo en la protección de rama, lo que convierte la misma señal en un bloqueador exactamente en las ramas que elijan. heygrc incluye el valor predeterminado neutral y admite la configuración de chequeo obligatorio.