Controles técnicos ISO 27001: acceso, cifrado, redes y desarrollo seguro

Si los controles organizativos son el gobierno del SGSI, los 34 controles tecnológicos del Anexo A son su músculo. Aquí es donde la ISO 27001 se encuentra con tu stack real: gestión de identidades, cifrado, hardening, backups, logs, redes y —la gran novedad de la versión 2022— desarrollo y codificación segura como controles de primera clase. Para una empresa que construye u opera software, este es el capítulo donde la certificación deja de ser un proyecto de documentación y se convierte en ingeniería.

Cuarto capítulo de nuestra guía completa de certificación ISO 27001. La buena noticia por adelantado: si tu equipo sigue buenas prácticas modernas —MFA, CI/CD con revisiones, infraestructura como código, backups probados— ya cumples buena parte del bloque. El trabajo es formalizar, cubrir huecos y generar evidencias. Vamos control por control, con su traducción a medidas concretas en entornos web y cloud.

1. Panorama: qué cubren los 34 controles tecnológicos

El tema tecnológico del Anexo A (controles 8.1 a 8.34) se agrupa de forma natural en siete bloques: identidades y accesos, criptografía, configuración y vulnerabilidades, copias de seguridad y continuidad, registro y monitorización, redes, y ciclo de vida de desarrollo. Cada control que actives debe trazar a un riesgo de tu análisis de riesgos — el auditor recorrerá exactamente ese camino: riesgo → control de la SoA → evidencia técnica.

2. Identidades y accesos: la primera línea

Los controles 8.2 a 8.5 piden gestión de derechos de acceso privilegiado, restricción de acceso a la información, acceso al código fuente y autenticación segura. Traducción operativa:

• MFA en todo acceso administrativo — panel cloud, WordPress/CMS, repositorios, correo, VPN. A estas alturas, resistente a phishing (llaves FIDO2 o passkeys) para los roles críticos.
• Principio de mínimo privilegio con roles definidos: nadie opera producción con permisos de administrador permanentes. Los accesos elevados se conceden temporalmente y se registran.
• Revisión periódica de accesos — trimestral para sistemas críticos. Es de las evidencias más pedidas en auditoría y de las más baratas de generar: una issue recurrente con checklist y acta.
• Cuentas nominales siempre — las cuentas compartidas («admin@», «dev@») son de las no conformidades técnicas más habituales. Si alguna es inevitable (root de emergencia), guárdala en el gestor de contraseñas con acceso auditado.
• SSO donde sea posible: además de mejorar la experiencia, convierte el alta/baja de personal en una operación de un clic — conectando este bloque con los controles organizativos de personal.

3. Criptografía: en tránsito, en reposo y con cabeza

El control 8.24 pide reglas para el uso efectivo de la criptografía, incluida la gestión de claves. En la práctica: TLS moderno en todo lo expuesto (con renovación automatizada de certificados), cifrado en reposo en bases de datos y backups, discos cifrados en portátiles, y secretos fuera del código — en un gestor de secretos o variables de entorno gestionadas, nunca en el repositorio. La política de criptografía documenta qué algoritmos se aceptan y quién custodia las claves; dos páginas bastan, pero deben reflejar lo que de verdad hay desplegado.

4. Configuración, hardening y gestión de vulnerabilidades

Tres controles trabajan juntos: gestión de vulnerabilidades técnicas (8.8), gestión de la configuración (8.9) y restricción de instalación de software (8.19). El patrón operativo que el auditor quiere ver:

• Inventario de software y versiones — sabes qué corre dónde, incluidas dependencias (un SBOM básico o el propio lockfile gestionado).
• Proceso de parcheo con plazos por severidad — crítico en días, alto en semanas, documentado y con excepciones justificadas. Aplica igual a sistema operativo, CMS y librerías: la mayoría de compromisos web explotan componentes sin parchear, como repasamos en la guía de seguridad WordPress para empresas.
• Configuraciones endurecidas y versionadas — si usas infraestructura como código (Terraform, Ansible, Docker), ya tienes gestión de configuración auditable; solo documenta la línea base.
• Escaneo periódico — dependabot/renovate en repositorios, escáner de vulnerabilidades sobre la infraestructura, y un pentest periódico que valide el conjunto con mentalidad ofensiva.

5. Backups y continuidad: el control que te salva la empresa

Copias de seguridad (8.13) y redundancia (8.14), más la preparación de las TIC para la continuidad (5.30) del bloque organizativo. La regla de oro sigue siendo 3-2-1: tres copias, dos soportes, una fuera del entorno principal — y hoy añadimos: al menos una inmutable o fuera de línea, porque el ransomware moderno busca y cifra los backups accesibles antes de detonar.

El matiz que separa cumplir de aparentar: restauraciones de prueba programadas. Un backup no probado es una hipótesis. Calendariza una restauración trimestral (basta con una tabla o un entorno efímero), mide el tiempo y regístralo: esa acta es simultáneamente tu evidencia de auditoría y tu RTO real.

Y pon números a la continuidad: RPO (cuántos datos puedes permitirte perder — determina la frecuencia de copia) y RTO (cuánto puedes estar caído — determina la arquitectura de recuperación). No los fijes en el vacío técnico: son una decisión de negocio que dirección debe firmar, porque cada hora menos de RTO cuesta dinero. Un RPO de 24h con backup diario puede ser perfecto para una web corporativa e inaceptable para una plataforma transaccional.

6. Logs y monitorización: ver lo que pasa

Registro de eventos (8.15), monitorización de actividades (8.16) y sincronización de relojes (8.17). Proporcional a tu tamaño: no necesitas un SIEM enterprise, necesitas logs centralizados de los sistemas críticos (accesos, errores, cambios), retención definida, protección contra manipulación y alertas accionables sobre los eventos que importan — logins administrativos anómalos, picos de errores, cambios de configuración, caídas. Para una plataforma web típica, un stack ligero (CloudWatch/Grafana/Loki o el equivalente de tu cloud, más las alertas del WAF) cubre el control con solvencia. La clave para el auditor: que puedas responder «¿quién accedió a X el día Y?» en minutos, no en días.

7. Redes: segregación y filtrado

Seguridad de redes (8.20-8.22) y filtrado web (8.23). En arquitecturas cloud modernas la segregación se expresa en VPCs y grupos de seguridad: producción aislada de desarrollo, bases de datos sin exposición pública, acceso administrativo por VPN o bastión con MFA. El filtrado web —nuevo en 2022— apunta a los equipos corporativos: DNS filtrado o protección de endpoint que bloquee dominios maliciosos. Y delante de las aplicaciones expuestas, un WAF con reglas actualizadas; el mismo principio que aplicamos al proteger servidores con poco presupuesto: capas, no muros únicos.

8. Desarrollo seguro: el bloque estrella para equipos de software

Los controles 8.25 a 8.34 forman un mini-marco de SDLC seguro: ciclo de vida de desarrollo seguro, requisitos de seguridad de las aplicaciones, arquitectura segura, codificación segura (8.28), pruebas de seguridad, desarrollo externalizado, separación de entornos, gestión de cambios, protección de datos de prueba y protección de sistemas en auditorías. Es el bloque que más pesa para una agencia de desarrollo o un SaaS, y donde el auditor con perfil técnico va a rascar. Lo que espera encontrar:

• Política de desarrollo seguro breve que fije las reglas: revisión de código obligatoria, gestión de dependencias, prohibición de secretos en repositorio, estándares de codificación (referencia natural: OWASP Top 10 y ASVS como guía de requisitos).
• Requisitos de seguridad en el diseño — en cada feature relevante, una pregunta sistemática: ¿qué datos toca, qué puede salir mal, qué necesita (authz, validación, rate limiting)? Un checklist en la plantilla de historia de usuario cumple el control.
• Pipeline con puertas de seguridad — el CI/CD que ya conoces, con SAST/linters de seguridad, escaneo de dependencias y de secretos. Si ya tienes un pipeline CI/CD maduro con tests y despliegues automatizados, añadir estas etapas de seguridad es un sprint, no un proyecto.
• Separación real de entornos (8.31) y datos de prueba protegidos (8.33): nada de copias de producción sin anonimizar en staging — aquí entra el enmascaramiento de datos (8.11).
• Gestión de cambios trazable (8.32): el flujo PR → revisión → merge → despliegue ES el control; solo asegúrate de que los cambios de emergencia también dejan rastro.
• Desarrollo externalizado (8.30): si subcontratas, los requisitos de seguridad viajan en el contrato y el código externo pasa las mismas puertas del pipeline.

La lectura estratégica: estos controles no te piden cambiar cómo desarrollas, te piden demostrar que desarrollas con disciplina. Un equipo con buen flujo de PRs, CI con tests y despliegues automatizados tiene el 70% de las evidencias generándose solas en el histórico de su repositorio.

8.1 Un apunte sobre IA en el desarrollo

Tema que ya aparece en las auditorías de 2026: si tu equipo usa asistentes de código (Copilot, Claude, Cursor), el SDLC seguro debe contemplarlo. Dos reglas mínimas en la política de desarrollo: el código generado por IA pasa exactamente las mismas puertas que el humano (revisión por pares, tests, análisis estático — sin excepciones «porque lo hizo la máquina»), y nunca se pegan secretos, datos personales o código propietario sensible en herramientas no aprobadas. Añádelo por escrito: demuestra al auditor que el SGSI evoluciona con tu forma real de trabajar, que es justo el espíritu de la mejora continua.

9. DLP y datos: los controles que llegaron con 2022

Prevención de fuga de datos (8.12), borrado de información (8.10) y enmascaramiento (8.11). Para una pyme tecnológica, la implementación proporcional: reglas DLP básicas en el correo y el drive corporativo (bloquear compartición externa de carpetas sensibles), política de retención y borrado alineada con RGPD (lo que no necesitas, se borra — con evidencia), y anonimización sistemática de datos personales en entornos no productivos. Nada exótico; disciplina de datos.

10. Checklist de prioridades: por dónde empezar

Si partes de una base media y tienes que ordenar la implantación técnica, este es el orden de máximo retorno por esfuerzo:

• Semana 1-2: MFA universal en accesos administrativos + gestor de contraseñas corporativo + eliminar cuentas compartidas.
• Semana 3-4: backups 3-2-1 con copia inmutable + primera restauración de prueba documentada.
• Mes 2: parcheo con plazos por severidad + escaneo de dependencias en CI + secretos fuera del código.
• Mes 3: logs centralizados de sistemas críticos + alertas accionables + revisión trimestral de accesos (primera acta).
• Mes 4: política de desarrollo seguro + puertas de seguridad en el pipeline + separación de entornos verificada.
• Mes 5-6: pentest externo que valide el conjunto y alimente el plan de tratamiento con hallazgos reales.

11. De control a evidencia: qué te pedirá el auditor en cada bloque

La pregunta práctica que recibimos siempre: «vale, ¿pero qué me van a pedir exactamente?». Este mapeo resume la evidencia típica por bloque técnico:

• Accesos: captura de la política MFA aplicada en el proveedor de identidad, matriz de roles, y las dos últimas actas de revisión de accesos con los cambios aplicados.
• Criptografía: informe TLS de tus dominios, evidencia de cifrado en reposo (configuración del RDS/discos), inventario de claves y quién las custodia.
• Vulnerabilidades y parcheo: el registro de parcheo de los últimos meses, un ejemplo de vulnerabilidad crítica gestionada dentro de plazo, y el informe del último escaneo con su plan de acción.
• Backups: configuración de las copias, y —la estrella— el acta de la última restauración de prueba con fecha, alcance y tiempo.
• Logs y monitorización: demostración en vivo («enséñame los accesos de ayer al panel»), lista de alertas configuradas y un ejemplo de alerta que se gestionó.
• Redes: diagrama de red/VPCs actualizado, reglas de los grupos de seguridad de producción, y cómo se accede administrativamente (bastión/VPN + MFA).
• Desarrollo seguro: la política, un PR real con su revisión, el pipeline con las etapas de seguridad ejecutadas, y cómo gestionasteis la última dependencia vulnerable.
• Datos: política de retención, evidencia de un borrado ejecutado y demostración de que staging no contiene datos personales reales.

Consejo de preparación: monta una carpeta (o página interna) de «evidencias técnicas» con enlaces vivos a cada una de estas fuentes. La fase 2 se acelera muchísimo y transmite exactamente la sensación de control que el auditor busca.

12. Errores técnicos que se repiten en auditoría

• El backup sin restauración probada. El clásico absoluto. «¿Cuándo restaurasteis por última vez?» — silencio.
• MFA en todo… menos en lo importante. MFA en el correo pero no en el panel del cloud o en el acceso SSH. El auditor (y el atacante) van a lo importante.
• Logs que nadie mira. Registro exhaustivo sin una sola alerta configurada. El control pide monitorización, no acumulación.
• Producción accesible desde cualquier sitio. Paneles de administración expuestos a internet sin restricción de origen ni MFA.
• Copias de producción en staging. Datos personales reales en entornos con la mitad de controles. Con RGPD encima, doble problema.
• Secretos en el repositorio. El escaneo retroactivo del histórico de Git da sustos en la mitad de los proyectos que auditamos.

13. El pentest como validación del conjunto

Puedes implantar los 34 controles y aun así tener huecos: configuraciones que se desviaron, una API olvidada, un flujo de negocio abusable que ningún checklist detecta. Por eso el cierre natural del bloque técnico es una validación ofensiva: un test de intrusión sobre el alcance del SGSI que intente romper lo que el papel dice que está protegido.

El momento óptimo es el mes previo a la auditoría interna: los hallazgos entran al plan de tratamiento con tiempo de corregirse, y el informe se convierte en una evidencia doblemente valiosa — demuestra el control de pruebas de seguridad (8.29) y alimenta la revisión de riesgos con datos reales en lugar de estimaciones. Un pentest anual, alternando alcance (aplicación web, infraestructura, ingeniería social), es el ritmo sano para una empresa tecnológica mediana; los detalles del enfoque los contamos en nuestro artículo sobre pentesting para plataformas online.

Conclusión: ingeniería con evidencias

El bloque tecnológico de la ISO 27001 premia a los equipos que ya trabajan bien: casi todo lo que pide es buena ingeniería con disciplina y rastro. Prioriza por riesgo, automatiza las evidencias dentro de tus herramientas (el repositorio, el CI, el gestor de tickets) y valida el conjunto con ojos externos antes de que lo haga el auditor.

Y no pierdas de vista el objetivo real: estos controles no existen para superar una auditoría, sino para que un lunes cualquiera —cuando llegue el phishing que alguien clicará o la dependencia comprometida— tu plataforma aguante, tus datos sobrevivan y tu equipo sepa exactamente qué hacer. El certificado solo lo atestigua.

En el próximo capítulo llega el momento de la verdad: la auditoría de certificación — cómo elegir entidad, qué pasa en la fase 1 y la fase 2, y cómo se gestionan las no conformidades. Y si llegas nuevo a la serie, el mapa completo está en la guía de certificación ISO 27001.