DevSecOps vs Consultoras en ISO 27001: Cuando el problema no es el estándar

¿Tu proceso ya existía… pero la consultora lo “descubrió”?

Hay algo que nadie dice cuando una organización inicia la certificación en ISO 27001:

El conflicto rara vez es técnico. El conflicto es organizacional.

Y si trabajas en DevSecOps, probablemente viviste algo así:

• Ya tenías gestión de vulnerabilidades madura.
• Tenías integración en CI/CD.
• Tenías métricas y SLA definidos.
• Tenías dashboard en producción.
• Tenías evidencia histórica.

Pero de repente:

• Aparece un Excel paralelo.
• Se duplican procesos.
• Se reformula lo que ya existía.
• Se asignan tareas que no estaban en tu scope.
• Y escuchas afirmaciones técnicamente incorrectas… dichas con total seguridad.

Entonces la pregunta no es:

¿Cómo cumplir ISO?

La pregunta es:

¿Cómo navegar ISO sin que destruyan lo que ya funciona?

ISO 27001 no está en contra de DevSecOps

Primero, algo claro:

ISO 27001 no compite con DevSecOps. Lo formaliza.

La versión 2022 del estándar exige, entre otras cosas:

• Gestión de vulnerabilidades (Control 8.8)
• Gestión de configuración (8.9)
• Seguridad en el ciclo de desarrollo (8.25)
• Separación de entornos (8.31)
• Monitoreo de actividades (8.16)
• Gestión de incidentes (cláusula 6 y control 5.24)

DevSecOps maduro ya cubre gran parte de esto.

El problema no es la falta de control. Es la falta de narrativa alineada al estándar.

Caso real: Gestión de vulnerabilidades duplicada

Escenario concreto:

El área ya tenía:

• Procedimiento formal versionado.
• Gestión integrada en GitLab Ultimate.
• Métricas de SLA.
• Dashboard dinámico.
• Evidencia trazable.

Pero la consultora:

• Creó un Excel.
• Reutilizó el procedimiento existente.
• Presentó el resultado como “nuevo proceso optimizado”.
• Solicitó tareas que estaban dentro de su alcance contractual.

¿Qué falló?

No fue el control 8.8.

Fue la comunicación estratégica.

Lección 1: Si no está formalmente mapeado, no existe

ISO exige evidencia objetiva.

No basta con que el proceso funcione. Debe estar:

• Documentado.
• Versionado.
• Aprobado.
• Asociado a controles específicos.
• Con responsables definidos (cláusula 5.3).

Preguntas clave que deberías poder responder:

• ¿Qué riesgo mitiga este proceso?
• ¿Qué control ISO cubre?
• ¿Cuál es la evidencia objetiva?
• ¿Quién es el responsable formal?

Si no puedes responder eso en 5 minutos, la consultora ocupará ese espacio.

Lección 2: El Excel no es el enemigo

El Excel duplicado no suele ser malicia. Es inseguridad.

Puede indicar:

• Falta de confianza en herramientas.
• Auditor acostumbrado a reportes estáticos.
• Desconocimiento técnico.
• Necesidad de evidencia “congelada”.

La respuesta madura no es confrontar.

Es preguntar:

• ¿Qué objetivo de control cubre el Excel que el dashboard no?
• ¿Es requisito del auditor o decisión interna?
• ¿Cuál es el análisis de eficiencia operacional?

Y luego proponer:

• Export automático firmado.
• Snapshot mensual.
• Evidencia controlada con hash.
• Registro versionado.

Eso es hablar el lenguaje ISO.

Lección 3: Bajo conocimiento técnico con alta seguridad discursiva

Este es el escenario más delicado.

No lo resuelves demostrando que sabes más.

Lo resuelves estructurando la conversación:

• “¿Cómo reduce eso el riesgo residual?”
• “¿Qué control específico del Anexo A estamos fortaleciendo?”
• “¿Dónde se documenta esa responsabilidad?”

Cuando llevas la discusión a riesgo y control, reduces el espacio para discurso vacío.

ISO certifica gestión del riesgo, no herramientas.

Lección 4: Cuando te asignan tareas que no corresponden

Este es el punto crítico.

Te piden:

• Redactar políticas estructurales.
• Diseñar matrices de riesgo completas.
• Armar documentación que forma parte del servicio contratado.

Nunca respondas:

Eso no me corresponde.

Responde:

• Solicito matriz RACI formal.
• Solicito revisión del alcance contractual.
• Solicito definición clara de Responsable vs Consultado.

ISO 27001 exige claridad de roles (cláusula 5.3). Úsalo como argumento técnico, no emocional.

El riesgo real en proyectos ISO

El mayor riesgo no es una vulnerabilidad sin parche.

Es:

• Ambigüedad de responsabilidades.
• Narrativa incorrecta.
• Ego profesional.
• Falta de comunicación.

He visto organizaciones con tooling impecable… y certificaciones frágiles.

También he visto organizaciones con tooling mediocre… pero documentación y narrativa impecables.

Adivina quién certifica más fácil.

DevSecOps como eje estratégico del SGSI

Si lo haces bien, la certificación puede ser una oportunidad para:

• Formalizar procesos ya maduros.
• Obtener presupuesto.
• Fortalecer métricas.
• Posicionar seguridad como función estratégica.

Pero requiere:

• Evidencia.
• Comunicación.
• Postura profesional.
• Claridad contractual.
• Visión de riesgo.

No se trata de defender tu trabajo. Se trata de proteger la arquitectura de seguridad de la organización.

Reflexión final

ISO 27001 no destruye procesos maduros.

La mala gestión organizacional sí.

La pregunta no es:

¿Cómo evito que la consultora interfiera?

La pregunta correcta es:

¿Cómo convierto la certificación en una ventaja estratégica para DevSecOps?

Porque si lo haces bien, no solo certificas.

Elevas el nivel de madurez real del negocio.