En el caso de vulnerabilidades muy críticas que han sido explotadas, el CISO querrá que los parches se apliquen inmediatamente, y el CIO probablemente esté alineado con esta urgencia. Pero para los parches de nivel medio, el CIO puede estar bajo presión para aplazar estas interrupciones a los sistemas de producción, y puede presionar al CISO para que espere una semana o incluso meses antes de parchear.
La misma tensión existe para los programas que afectan a la experiencia digital del cliente. Por ejemplo, una nueva funcionalidad de autenticación multifactor requiere nuevas comunicaciones con el cliente y quizás la correspondiente interrupción a corto plazo del canal, algo que puede ser difícil de aceptar para la empresa.
O el CIO y el equipo de ingeniería pueden estar trabajando con unidades de negocio para facilitar nuevas funciones de cliente a través de una plataforma API. Desde la perspectiva del CISO, esas API deben gestionarse adecuadamente, e incluso someterse a pruebas de penetración, para garantizar que no crean un vector inesperado de pérdida de datos. El CISO querrá que se apliquen más controles, pero el CIO, aunque esté de acuerdo en principio, también debe satisfacer a las partes interesadas garantizando la entrega de la función, a menudo en un plazo breve.
La gestión de incidentes es otro campo propicio para la tensión. El CISO tiene un papel de liderazgo que desempeñar cuando se produce un incidente cibernético grave o una interrupción del negocio, y a menudo es el ‘mensajero’ que comparte las malas noticias. Naturalmente, el CIO quiere ser informado de inmediato, pero a menudo los detalles son escasos y con muchas incógnitas. Esto puede hacer que el CISO quede mal ante el CIO, ya que a menudo hay más preguntas que respuestas en esta primera etapa.
Un quinto ejemplo es DevOps, ya que muchos CIO, entre los que me incluyo, abogan por la entrega continua a gran velocidad. Desgraciadamente, no tantos CIO abogan por DevSecOps para integrar las pruebas de ciberseguridad en el proceso. Esto se debe quizás a que el CIO a menudo está bajo la presión de las partes interesadas ejecutivas para liberar nuevas compilaciones de software y así aceptar el riesgo de que pueda haber alguna iteración necesaria si esto no es perfecto. Mientras tanto, no muchos CISO provienen de un entorno de desarrollo de software, por lo que a menudo no se sienten cómodos participando y desafiando este proceso.
Cómo se relacionan los distintos arquetipos de CIO y CISO
Las anteriores áreas de fricción no tienen nada que ver con las personalidades del CIO y el CISO, un problema adicional de incompatibilidad que puede crear más tensión en la relación. Es probable que el CIO y el CISO hayan llegado a sus puestos a través de diferentes trayectorias profesionales y pueden tener un enfoque diferente de su trabajo. Algunos de estos arquetipos resultantes funcionan naturalmente mejor juntos, mientras que otros pueden chocar. Mi consejo aquí es que consideres cómo funciona tu contraparte, cuál es su estilo natural y cómo podrías abordar los posibles puntos de presión de manera diferente. Por ejemplo, un CIO empresarial o un CIO colaborador valorarán el compromiso de las partes interesadas como clave para el éxito. Si se empareja con un CISO técnico o un CISO transformacional, puede haber cierta incompatibilidad de enfoque.
