Archivo del sitio
El Auditor de Sistemas como consultor en la organización
Una empresa exitosa no debería inventar cada procedimiento, proceso o práctica operativa que necesite para lograr sus objetivos. La industria en todas sus ramas ya se ha encargado de la definición de las mejores prácticas, definiéndolas a través de normas o estándares que facilitan su adopción. Sin embargo, los auditores siempre identificamos situaciones que denotan la falta de utilización de estos marcos de referencia en una operación. En general las empresas tienen problemas para adoptar marcos de referencia que les ayuden a lograr sus objetivos de una manera más efectiva. Esto está ligado a la escasa vinculación que la educación universitaria brinda a los profesionales de todas las áreas, incluidas las áreas de Tecnologías de la Información y de Auditoría Interna, con procesos de adopción de estándares y a veces con el conocimiento de los mismos. Esta es definitivamente una oportunidad para que los Auditores de Sistemas aportemos valor a las organizaciones.
Cuando se trata de las Tecnologías de la Información, los Auditores de Sistemas nos enfrentamos en muchas ocasiones con personal que no ha estado expuesto al conocimiento de normas de gestión de TI o de la identificación de mejores prácticas en la industria que son necesarias, sino indispensables para el uso efectivo de la inversión en tecnologías que la organización ha realizado o para minimizar riesgos de seguridad, especialmente en el entorno actual en el que siempre existen amenazas acechando la oportunidad de explotar vulnerabilidades en la infraestructura de TI. Por otro lado, los Auditores de Sistemas, interesados en cumplir con los códigos de ética que nos indican que tenemos que hacer nuestro trabajo con profesionalismo, siempre estamos buscando la actualización de los últimos estándares y ofertas de la industria
En este contexto, un Auditor de Sistemas puede diseñar su plan incluyendo actividades de consultoría en la aplicación de normas, estándares y mejores prácticas. Esto tiene mucho sentido porque si se ha identificado un riesgo, porque no orientar el esfuerzo de mitigación que la organización puede seguir. El trabajo de consultoría puede seguir la siguiente ruta:
- IDENTIFICACIÓN. Consiste en la identificación de principales riesgos que pueden ser cubiertos por la aplicación de una norma o estándar. Esta fase debería de aportar la información para priorizar la aplicación de normas. Es decir, la organización debe de realizarse un examen y definir sus prioridades en la implementación de estándares. Esto es importante porque no se puede empezar a implementar todos los estándares existentes, así que debe priorizarse que interesa más a la organización: gestión de TI, gobierno de TI, Seguridad de la Información, Gestión de riesgos, Calidad, etc.
- El Auditor de Sistemas puede compartir su conocimiento con el personal de TI para dar a conocer al personal de la organización el contenido de las normas aplicables. Esto ayudaría nivelar el conocimiento sobre las normas y posibles rutas de acción que motivarían la adopción de un marco de referencia.
- PRIORIZACIÓN DE ACCIONES. En esta fase, el Auditor de Sistemas debe facilitar un proceso para orientar un esfuerzo de decisión sobre las prioridades de implementación. Es importante establecer el rol de consultor, que implica el no decidir prioridades de implementación por los responsables de la gestión de TI, ni participar activamente en la implementación de las normas. El punto es colaborar en crear un Plan de Trabajo que posteriormente los responsables de la gestión de las TI pueden seguir.
Seguir este proceso ayudará a posicionar el valor de la Auditoría de Sistemas en la organización, especialmente si se cumple el plan de implementación de estándares y la organización materializa los beneficios.
¡Terremoto en Costa Rica! Ayer se probaron los Planes de Contingencia Tecnológica.
No cabe duda que los fenómenos naturales que causan desastres suceden tarde o temprano. Me parece que esa parte de la realidad es conocida y en las organizaciones se espera que suceda lo más tarde posible, lo suficiente como para estar preparados para afrontar la contingencia. Por supuesto, ante un desastre natural del tipo que aconteció ayer en Costa Rica, lo primero es salvaguardar las vidas humanas, la seguridad de la integridad física de las personas. Pero posteriormente al evento, en momentos en los que aún se está sufriendo la experiencia de pasar por el evento, hay que asegurar que los activos de la organización serán protegidos. Leía la noticia sobre como algunas agencias bancarias cerraban “por precaución” y me preguntaba si esa era una medida ya calculada, “paso uno del plan de contingencia tecnológica en caso de terremoto”. Otras noticias decían que las comunicaciones habían tenido problemas en la primera hora posterior al evento. Esto es un impacto en las comunicaciones, que bien podría haber dejado partes de la red de datos de una organización sin acceso. “Paso número 2”, definir el estado de funcionalidad después del evento catastrófico. La verdad es que en esos momentos las decisiones tienen que ser bien medidas. El Gerente del Proceso de Contingencia o el Líder de Contingencia tiene primero que buscar la información y si la obtiene, tomar la mejor decisión a partir de lo que sabe. Si no la obtiene, aún tendrá que tomar la decisión de qué hacer, pero con un margen de error más grande.
Cuando se diseñan los Planes de Contingencia, siempre es bien difícil hacer entender al personal de una organización que hay que pensar en los escenarios de un evento que obligue a la activación del Plan de Contingencia. Por ejemplo, después de un terremoto, podría ser que se cuenten con los empleados claves. En ese escenario, ellos realizarán las actividades claves de recuperación ejecutando los roles que normalmente desempeñan. Escenario 2, no está disponible un empleado clave por las mismas causas del evento. Este escenario obliga a pensar de antemano en la persona, o personas en una cadena de sucesión, que retomarían sus funciones. Este escenario obliga a crear también relaciones de comunicación entre los funcionarios claves y sus sucesores en caso de contingencia. Obliga a establecer capacitaciones para los sucesores. Obliga a revisar que la documentación de los procesos este clara y actualizada, así como obliga a la lectura por parte de los sucesores, quienes podrían incluso hacer observaciones que mejoren la documentación existente. Esos escenarios y muchos más, son los que se tiene que pensar de antemano cuando se está creando un Plan de Contingencia Tecnológica. Escenarios con sus consecuencias en términos de personas involucradas, conocimiento identificado como crítico, capacitaciones y mejor documentación.
Quizá el principal problema del personal en las organizaciones es la falta de imaginación. Siempre la usamos para imaginar lo mejor, por lo que imaginar que sucede algo malo, de carácter catastrófico, nos hace dudar de cuales serían los escenarios de un evento catastrófico. La recomendación es: ¿Tiene su organización un Plan de Contingencia para afrontar estos escenarios? Si la respuesta es no, tienen trabajo y ojalá el tiempo para hacerlo sea menor que lo que falta para el siguiente evento catastrófico.
Gestión y Auditoría de TI 