Fundamentos de la auditoría de TI

1. 1. INTRODUCCIÓN: Hola, y bienvenidos al curso Fundamentos de auditoría de TI. Mi nombre es paciente y como tu instructor, mi objetivo es compartir contigo los principios fundamentales de la auditoría de TI. Este curso es un bloque de construcción fundamental que es importante para obtener una mejor comprensión de la TI. Auditoría y controles probados. 2. 2. Introducción a la auditoría y controles de TI: Bien, comencemos con la primera conferencia, Introducción a la auditoría y controles de TI. En esta conferencia, cubriremos los siguientes ítems. Vamos a definir TI, auditorías, controles definidos, explicar la jerarquía de los controles, razones de los controles y elementos de los controles. También revisaremos los tipos de control y repasaremos varios ejemplos para que se sienta cómodo con el concepto de controles. Entonces primero, ¿qué es una auditoría de TI? En la pantalla se puede ver lo que yo llamo la definición más formal de auditorías de TI. Sin embargo, en términos simples, una auditoría de TI es simplemente un examen de los controles que están integrados en y alrededor del sistema de TI. Y estos controles son evaluados para su efectividad. Eso significa que estamos evaluando para determinar si está funcionando de la manera que se supone que debe ser. Es fácil mitigar el riesgo que se diseñó para atender o cumple con los requisitos mínimos de cumplimiento? Quizás te estés preguntando, ¿qué es un control? Si no sabes lo que es un control en estos momentos, está bien. Aguanta. cubriremos un poco más tarde. Una cosa que sí quiero cubrir aquí es que cuando se realizan auditorías de TI, solo brindan una garantía razonable con respecto a la integridad y precisión de los datos en los sistemas de TI. No brindan una garantía absoluta porque siempre son aspectos del entorno de control que no pueden contabilizarse. Por ejemplo, los controles automatizados pueden sentir que tal vez un sistema falla. O un control manual puede ser anulado por cualquier ser humano. O puede tener objetivos de control que no están diseñados adecuadamente para empezar. Se. Las auditorías no pretenden ser absolutas. Solo pueden dar garantías razonables con respecto a la integridad y exactitud de los datos en los sistemas informáticos. Bien, a continuación, definamos los controles. Lo que nuestros controles. Nuevamente, en la pantalla se puede ver una definición más formal de controles. Pero en términos sencillos, un control es como una actividad de punto de control que se implementa para reducir el riesgo de que ocurra una acción no deseada. El objetivo de un control es mitigar los riesgos que pueden impedir que la empresa logre sus objetivos corporativos. Los riesgos podrían ser riesgos de cumplimiento, riesgos operativos, riesgos de reputación o incluso riesgos de informes financieros. Entonces el control es la actividad que se implementa para reducir ese riesgo. Ahora, hablemos de controles clave, porque puede haber varios, incluso cientos de controles en una organización. Sin embargo, normalmente solo un subconjunto de ellos se consideran controles clave. Los controles Keep son los controles que son realmente vitales para proteger la integridad de los sistemas desde una perspectiva de cumplimiento o desde cualquiera de las otras perspectivas del área de riesgo, como se señala en la diapositiva. Y se puede ver que se requieren sus controles clave para lograr un objetivo. El fracaso de un control clave generalmente tiene un impacto significativo en la organización. Si un control que no es clave lo llena a veces, ¿de acuerdo? Pero si una clave controla los campos, eso generalmente significa que hay un problema mayor. Entonces, vamos a tener un ejemplo aquí. Por ejemplo, un control clave puede estar limitando acceso para realizar cambios en el balance general. Es decir, hay un control que limita a los individuos que pueden cambiar el balance directamente. Si ese control se llena, significa que la información del balance puede no ser confiable porque otra porque una persona no autorizada puede haber realizado cambios inapropiados. Por favor, quiero que tenga en cuenta que un profundo conocimiento de los controles, cómo se definen e implementan es clave para su éxito como auditor de TI. Mi creencia es que necesitas entender por qué estás probando un control antes de poder diseñar de manera efectiva cómo pruebas ese control. Si no entiende lo que protege el control, por ejemplo, el balance general o las aprobaciones de pago de facturas, la prueba que diseña y realiza puede no ser adecuada para abordar el riesgo de ese control no se está implementando adecuadamente. Bien, hablemos de la jerarquía de controles. Esta imagen representa la jerarquía de controles o control que normalmente existe para cumplir con un objetivo de control. Un ejemplo de un objetivo de control podría ser uno. Los controles proporcionan una garantía razonable de que acceso al sistema de cuentas por pagar se limita a autorizar a las personas. O segundo, los controles brindan garantías razonables de que acceso para realizar cambios en los sistemas financieros se limita a autorizar a los individuos. Estos son objetivos de control. Para cumplir con estos objetivos de control, controles como los controles de acceso de usuarios, lo que limita. Personas que pueden acceder a esas áreas o controles de contraseña que determina o ordena que las contraseñas deben ser utilizadas para acceder a esos sistemas. Y se implementan controles de privilegios. A continuación, voy a controlar el objetivo está en su lugar para cumplir con un objetivo de auditoría. Un ejemplo de objetivo de auditoría es que existe una certeza razonable de que los estados financieros pueden ser confiados y están libres de errores materiales. O para la auditoría relacionada con PCI, un objetivo de auditoría podría ser que haya garantía razonable de que sistema procese los pagos de manera adecuada, rápidamente segura para proteger la información del cliente. Por lo que los objetivos de esta auditoría son el nivel superior. Ellos son el nivel superior lo que hay que lograr. Para lograr el objetivo de auditoría, tenemos que bajar al objetivo de control que lo desglosa aún más. Y luego para lograr un objetivo de control, es necesario contar con los controles reales que te van a ayudar a cumplir con ese objetivo. Y como puede ver en la diapositiva, el objetivo de la auditoría suele ser el propósito de la auditoría, lo que el auditor espera lograr. Y entonces el objetivo de control los objetivos de gestión que se utilizan como marco para desarrollar e implementar controles con el fin de cumplir con el objetivo general. Bienvenidos a la segunda parte de la conferencia sobre auditoría y controles de TI. Comenzaremos con los motivos de los controles. Entonces, discutamos por qué las organizaciones implementan controles. Los controles se implementan por muchas razones diferentes. Una que tengo aquí es la confiabilidad de la información financiera. Las organizaciones deben demostrar que tienen controles establecidos para proporcionar garantías razonables de que los informes financieros son precisos y pueden ser confiados por claves públicas o privadas, los grupos de interés. Entonces, para poder mostrar estos, las organizaciones necesitan demostrar que tienen controles establecidos para permitir esa garantía. Otro elemento que tenemos aquí es el cumplimiento de las leyes y regulaciones aplicables. Los controles se implementan porque las leyes y regulaciones requieren que sean implementados. Por ejemplo, el Reglamento Sarbanes-Oxley requiere que la administración proporcione una afirmación sobre los controles que han implementado y probado en torno a su proceso de informes financieros. Esto se llama Eco para los controles internos sobre la información financiera. Otros ejemplos incluyen las normas regulatorias PCI y SSE 16. Esto también requiere que se implementen controles para que puedan probarse según corresponda base en esos estándares en particular. Otra razón para los controles sería lograr la efectividad y eficiencia de las operaciones. Cuando las organizaciones tienen controles, ciertas actividades operativas se simplifican más y están mejor posicionadas para ayudar a la organización a lograr sus objetivos. Si bien esto puede no estar relacionado con ciertas leyes y estándares, siguen siendo cruciales para el éxito de la compañía. Por ejemplo, existen controles alrededor de las prácticas de contratación de recursos humanos para garantizar que los candidatos calificados sean contratados O podría haber controles en torno a la protección de secretos comerciales o fórmulas. Otra razón para los controles es que ayudan a lograr procesos definibles y repetibles que mejoran la consistencia de los resultados operativos. Cuando los controles se implementan adecuadamente, ciertas actividades se vuelven repetibles y estandarizadas y potencialmente incluso automatizadas para garantizar la consistencia continua de los procesos. Por ejemplo los informes de saldo de prueba pueden revisarse periódicamente para identificar y abordar cualquier discrepancia en los libros financieros. Además, puede tener controles de conciliación que se implementan para garantizar que los saldos financieros estén siempre sincronizados entre las entidades para que pueda identificar y abordar rápidamente cualquier discrepancias. Por lo tanto, desea poder verificar los artículos con frecuencia para asegurarse de que las cosas que se supone que deben estar sincronizadas o aún incidentes. Por último y definitivamente no la lista del sistema de seguridad del sistema de seguridad garantiza que se implementen controles para mantener o al menos disuadir a los malos de acceder a los sistemas. Controles de acceso de usuarios, controles de contraseña, controles de red, ejemplo, configuración de firewall. Todos estos se implementan para garantizar que solo los usuarios que estén autorizados y apropiados o accedan a los sistemas. Por lo que esto da una visión general de algunas razones para los controles. A continuación, repasaremos elementos de controles. Los controles deben tener ciertos elementos para calificar como controles adecuados. Dependiendo del tipo de control, es posible que no tenga todos los elementos enumerados en esta diapositiva. No obstante, debe tener suficiente de estos elementos para que se considere adecuado. Ejemplo adecuado de un control. Voy a leer un ejemplo y luego repasaremos este elemento. Se requieren contraseñas antes de acceder al sistema. Por lo que esta es la verificación de contraseña u otro control es el acceso al sistema requiere un formulario de solicitud de acceso de usuario completo y la aprobación del gerente. Esos son controles para elementos específicos en el sistema. Entonces el primer elemento es, ¿qué es una actividad de control? ¿Cuál es la actividad de control? Por ejemplo, podría ser un control de autenticación y un control de autorización, un control de contraseña, como lo que acabo de leer. Control de acceso o libros, control de conciliación. Tu control tiene que exponer cuál es la actividad en uno de los ejemplos que leí antes, parte de eso es la aprobación de un formulario de solicitud de acceso por parte de un directivo. El segundo elemento aquí es la frecuencia con la que ocurre el control, que es la frecuencia. Podría ser por hora, diario, semanal, o incluso M0. Y también podrías tener un control automatizado que es solo el cheque frecuente. Entonces quieres exponer cuál es la frecuencia. Y si no hay una frecuencia establecida, si es automatizada, también quieres configurarla. Voy a pegar eso también más bien. Otro elemento es el título la OMS que está realizando el control. Y si hay alguna segregación de deberes involucrada, ¿hay algún conflicto potencial con la persona que realiza el control, el gerente que aprueba el formulario no debería ser la misma persona que crear acceso en el sistema, por ejemplo, desea asegurarse de que tiene una separación de deberes en su lugar. Por lo que se quiere exponer el título de la persona que realiza el control. En un ejemplo que dije anteriormente, el gerente es la persona o comprobó la forma, pero luego el acceso al sistema normalmente lo otorga el administrador y es posible que desee incluirlo en control. Otro elemento aquí es ¿ cuándo ocurre la actividad de control? ¿Hay algún momento específico de la base de datos que sea importante tener en cuenta? Entonces, por ejemplo, a. revisión diaria de las entradas de la revista puede ocurrir a las 04:00 P.M. todos los días antes del cierre del negocio o ¿ ocurre después de actividades específicas? ¿Tiene antecesores en el proceso? Entonces tal vez quieras pegarte todo esto. También es posible que desee indicar algo así como una actividad de cuenta de usuario con privilegios temporales que puede tener lugar después de que un usuario se haya bloqueado. Entonces, si hay alguna secuencia específica para ese control, Eso es algo que considerarías agregar al control. Otro elemento que tenemos aquí es si hay algún archivo de documento de informe que se va a utilizar para realizar el control, puede ser razonable incluirlo en control. ejemplo, si existe un control con respecto revisiones de acceso de los usuarios y necesita generar un informe de acceso específico desde el sistema. Es posible que quieras pegar eso en los controles para que quede claro de qué se trata ese control. O si son cheques cruzados balanceados, cheques cruzados de saldo de cuentas que requieren reportes de diferentes sistemas específicos. Es posible que desee afirmar eso para que quede claro qué sistema o qué informes se están conciliando. Por último, pero no menos importante, tenemos evidencia que se produce como resultado de realizar el control. Entonces, cuando se haya realizado el control, ¿qué pruebas se conservarán para demostrar que el control se realizó realmente? Por ejemplo, eso podría ser un informe con los resultados de revisar el acceso de los usuarios o un informe muestre los saldos de las cuentas que se conciliaron. Es algo que puedes considerar incluir en tu control. Ahora sé que hemos hablado mucho de controles, pero una cosa importante a notar aquí en la diapositiva, un proceso no tiene el control. El proceso apoya el control. El objetivo de control no es el control. El objetivo de control es simplemente el objetivo del control. Y último elemento es que las pruebas se realizan sobre el control real. Es importante conocer la diferencia entre un control que es la actividad del punto de control y el proceso que rodea a los soportes que controlan. Y luego el objetivo final de control que muchos controles clave van a soportar. Con esto concluye esta parte de la conferencia y la siguiente parte de la conferencia, hablaremos de tipos de control. Bien, bienvenidos a la siguiente parte de esta conferencia. Empezaremos hablando de tipos de control. Existen diferentes tipos de controles, y estos son los tres tipos principales de controles. Puede encontrar otros textos u otros tipos de control en los textos de auditoría, pero estos suelen ser categorías más pequeñas. Estas son las principales categorías de tipos de control. El primero que tenemos en los controles preventivos. Se implementan controles preventivos para evitar que ocurra un evento indeseable. Por lo que estos controles se ponen en marcha para tratar de evitar que algo malo suceda. Por lo que el desarrollo de estos controles implica tratar de predecir los problemas potenciales que podrían ocurrir y luego implementar formas de evitar esos controles, por ejemplo , contraseñas, requiere que las personas ID de inicio de sesión y contraseñas antes de que puedan ingresar a los sistemas. O puedes tener otra lista, control de privilegios, es decir, solo das acceso a las personas a lo que necesitan para desempeñar su función laboral. Entonces, al hacer esto, estás previniendo posibles problemas en el futuro. La siguiente pestaña de control son los controles de detective. Se implementan controles de detectives para identificar eventos indeseables que ya han ocurrido. Entonces, por ejemplo si su control preventivo no pudo evitar que algo sucediera, desea tener controles de detectives establecidos para que realmente pueda identificar si algo que ya sucedió. Por lo que esto podría ser una revisión periódica del acceso habitual para asegurarse de que sólo los individuos adecuados para tener acceso. O puede tener varios controles de alerta y administración de eventos que notifican cuando ocurren problemas. Entonces todos estos caen bajo los controles de detectives. Y la tercera categoría aquí, los controles correctivos. Los controles correctivos están diseñados para corregir errores o irregularidades que se hayan detectado. Entonces, si ya tienes problemas que están en curso y estás pensando en formas de solucionarlos. Ahí es cuando traes controles correctivos. Y un buen ejemplo para los controles correctivos es el entrenamiento o reentrenamiento del usuario. Si identificas que el error de usuario es la razón por la que muchos controles preventivos preventivos están fallando, entonces es posible que quieras volver a entrenar o capacitar a los usuarios si no fueron entrenados inicialmente. Ahora, repasemos algunos ejemplos de control. Los ejemplos que tengo en la pantalla aquí están en ningún orden en particular, así que simplemente los revisaremos. El primero en pantalla es la autorización de acceso. Y el control. acceso del usuario a la aplicación debe ser autorizado por el administrador del individuo antes de que se otorgue el acceso. Aquí verías el elemento de control que habla de lo que es la actividad, que es la aprobación o autorización por parte del gerente del individuo. Y entiendes que eso debería ocurrir antes realmente se otorgue el acceso al usuario en la aplicación. Por lo que se puede ver que algunos de los elementos que discutimos anteriormente se encuentran en este control particular. El siguiente ejemplo que tenemos en la lista es el acceso administrativo, y dice que el acceso de súper usuario a la base de datos de SQL Server está restringido a los DBA. Nuevamente, esto también tiene el elemento de decir quién es esta restricción dos. Porque ves aquí que se está hablando primero del acceso de súper usuarios en la base de datos. Y parecía que solo las personas que tienen un rol laboral de DBA deberían tener acceso de superusuario. Y te dice lo que es la base de datos SQL Server, nuevamente, se puede ver donde se han cubierto algunos de estos elementos de control que discutimos estos elementos de control que discutimos anteriormente. El tercer ejemplo que tenemos es sobre el acceso de usuario terminado. Y se lee, a todos los usuarios terminados se les quita su cuenta de red dentro de los dos días siguientes a la terminación. Esto también es muy claro. Se trata de usuarios terminados. Se trata del eje, específicamente el acceso a la cuenta de red y se le da una duración de dos días. Dentro de los dos días siguientes a la terminación, acceso a la red debe ser eliminado Entonces es muy claro de qué trata esta actividad de control en particular. Y el último que tenemos en pantalla es un control de contraseña que lee. La base de datos Oracle requiere que los usuarios tengan contraseñas con al menos ocho caracteres alfanuméricos, y la contraseña debe cambiarse al menos cada 90 días. Nuevamente, se puede ver que esto es muy específico. Te está diciendo que esto es para la base de datos Oracle específicamente. Y te está diciendo las características o la frase, los ajustes de configuración que deben estar habilitados. Por lo que la configuración de la contraseña debe tener ocho caracteres alfanuméricos que se anoten. Y luego también quieres asegurarte de que haya una configuración de exploración que diga que una contraseña caduca después de 90 días, hora en la que se debe cambiar. Aquí hay algunos ejemplos de control adicionales. Este primero dice acceso físico y lee, acceso al centro de datos está limitado al personal de TI. Y éste también es muy claro. Se trata del centro de datos y el acceso, y se trata de los roles del personal de TI que debe tener acceso. Este control podría mejorarse al afirmar si hay algún grupo dentro del grupo de TI que deba tener acceso o no debería tener acceso. Eso podría ser una mejora a este control donde eres un poco más específico sobre quién debería tener acceso al centro de datos. El siguiente control que tenemos en la pantalla es el cambio de gestión. Todas las solicitudes de cambio a los sistemas de la organización deben ser debidamente autorizadas, probadas y aprobadas antes de su implementación. Esto también tiene algunos de los elementos que discutimos porque puedes ver aquí estamos hablando de las solicitudes de cambio. Esa es la parte del control y te dice las actividades específicas que tienen que ocurrir para las solicitudes de cambio, lo que incluye autorización, pruebas y aprobación antes de implementarlo en producción. Por lo que aquí falta la palabra producción. Esa es una mejora que podríamos agregar. Pero se puede ver aquí que varios elementos están presentes para que quede muy claro. Este control es sobre el último control que tenemos aquí, es capacitación en políticas de TI? Y esto afirma que la orientación de nuevas contrataciones incluye capacitación básica en concientización de seguridad Y al finalizar, se requiere que la nueva contratación firme que concluyeron la capacitación. Y puedes ver aquí que te está diciendo lo que está ocurriendo. La actividad que está ocurriendo es la capacitación en concientización de seguridad. Y puedes ver aquí que la evidencia de que ese control se lleva a cabo o se está realizando es la firma del nuevo empleado que dice que en realidad han completado la capacitación. Y puedes ver algunos elementos entrando en juego aquí. Como se discutió anteriormente. Todos los elementos que cubrimos hace algunas diapositivas no necesitan estar presentes en cada control, pero se necesita una buena cantidad de alcohol para asegurarse de que el control sea muy claro. Bien, hemos llegado al final de esta sección. Hablemos de los artículos que hemos aprendido en esta conferencia. Aprendimos sobre la definición de auditoría de TI. También aprendimos sobre la definición de controles y controles clave. Revisamos la jerarquía de controles, las razones detrás de los controles, por qué las organizaciones implementan los controles. También repasamos los elementos básicos de los controles. Y luego discutimos los diferentes tipos de controles, los tres tipos principales de controles, y cerramos eso con ejemplos de control. Muchas gracias por escuchar esta conferencia. Nos vemos en la próxima conferencia. 3. 3. Controla la prueba y el muestreo: Bienvenido a la sección de pruebas de controles. Ahora que sabemos qué son los controles, hablemos de pruebas de controles. Aquí están los artículos que abordaremos en esta sección. Vamos a revisar. ¿Por qué probamos los controles? Los tipos de controles que probamos, los tipos de pruebas que realizamos y cómo hacer selecciones para las pruebas. Entonces en esta primera conferencia aquí, la pregunta es, ¿por qué probamos los controles? La razón clave, la razón principal es que probamos controles para determinar si están cumpliendo con el propósito para el que fueron implementados. Si un control no está cumpliendo el propósito para que Egipto se implementó, entonces es ineficaz y puede ser necesario cambiarlo. Entonces no basta con decir, he diseñado e implementado controles en el entorno. Es absolutamente necesario probar esos controles periódicamente para asegurarse de que realmente están realizando y haciendo el trabajo para el que se implementaron. Y si hay alguna brecha, entonces la gerencia necesitará tomar la decisión sobre cómo cambiar esos controles según corresponda. Hablemos de los tipos de controles que probamos. Hay dos amplias categorías de controles. Es controles generales, o algunas personas pueden llamarlo generales de TI y controles de aplicaciones. Los controles de aplicación son específicos ciertos procesos de negocio que ocurren en una aplicación. Y B suelen basarse en la personalización de una aplicación por parte del cliente. ejemplo, los controles de aplicación serán controles sobre los límites de aprobación, autorizaciones de pago, por ejemplo, esta persona solo puede aprobar hasta X dólares para el pago. O también puede tener autorización para editar entradas de diario específicas o acceder a ejecutar y ver informes específicos de recursos humanos. Para una auditoría regulatoria, el equipo de auditoría, el equipo de auditoría financiera que normalmente se identifica, la aplicación controla que forman parte del alcance de la auditoría. Es importante tener en cuenta que los controles de aplicaciones son alcohol ellos, los controles de negocios que impulsan los controles generales de TI que se prueban. Por otro lado, los controles generales de TI o puede verlos denominados GCS de TI. Y nos referimos a ellos como eso. Son controles generalizados que apoyan el entorno de TI de la organización y el impacto de múltiples aplicaciones en uso por la organización. ¿Qué significa eso? Esto significa que los controles generales de TI soportan todo el entorno de TI, lo que incluye la aplicación específica que puede estar en el alcance de una auditoría. Generalmente, los GCS de TI, necesitan estar operando de manera efectiva para que se confíe en los controles de la aplicación. Hablemos a través de un ejemplo solo para aclarar un poco las cosas. Controla en general las contraseñas y el acceso, que veremos algunos ejemplos en nuestra sección anterior. Debido a que estos son para autenticación y autorización, ayudan a garantizar que las personas necesitan ser autenticadas en el entorno de TI antes de poder acceder a los sistemas donde tienen autorización . Si estos controles no están operando de manera efectiva, significa que muchos usuarios pueden acceder a las aplicaciones financieras sin la autenticación adecuada. Y pueden acceder a partes de la aplicación sin la debida autorización. Será bastante difícil demostrar que solo los usuarios autorizados tienen acceso a las aplicaciones de finanzas. Personas no autorizadas pueden tener acceso para aprobar pagos en la aplicación debido a que los controles generales de TI no fueron efectivos. Este ejemplo va a mostrar la importancia de la TI. Los controles generales que son efectivos para que los auditores sean aquellos que están probando para confiar en los controles de esta aplicación. En la siguiente diapositiva, pasaremos por un ejemplo pictórico. Esta diapositiva de aquí es una imagen que representa lo que acabamos de discutir. Entonces puedes ver aquí el entorno de TI es el gran círculo. El general de TI controla toda la red, servidores, bases de datos y aplicaciones. Todos los controles son abarcadores. Bueno, no debería decirlo todo, pero tienen un alcance lejano y son muy penetrantes. Y se puede ver que abarca diversos sistemas de aplicación que están en su alcance. Sin embargo, puede ver que cada sistema tendrá sus propios controles de aplicación específicos que son específicos de los procesos dentro de esa aplicación, dependiendo de cuál de estos sistemas esté en alcance para una auditoría, primero necesita probar el entorno general de TI y ver cómo las fiabilidades, que luego determinará el alcance de las pruebas que se realizarán en cada sistema individual. Así que espero que esto te haya dado un poco más de claridad sobre las diferencias entre TI, controles generales y controles de aplicaciones. Ya que este curso se trata aquí de la auditoría como algunas subcategorías de los controles generales de TI. No profundizamos en esto en este curso en particular, pero es bueno darles una visión general de cuáles son las subcategorías. Las categorías son de seguridad lógica, que tiene que ver con el acceso. También contamos con cambios de programa, desarrollo de programas, operaciones informáticas, controles físicos y ambientales. Ahora, vamos a discutir los tipos de pruebas que realizamos para los controles. Para probar los controles, primero hay que determinar si el control está diseñado adecuadamente antes de determinar si está funcionando de manera efectiva. La prueba de diseño es determinar si un control está diseñado correctamente, tal manera que si se implementara como se diseñó, operaría de manera efectiva. Esto significa que se prueba el control para determinar si hay alguna brecha o problema que impida que funcione tal como está diseñado. Por ejemplo, echemos un vistazo a los controles de contraseña. Si quieres probar el diseño de los controles de contraseña que se recogen, las contraseñas deben ser alfanuméricas. Desea asegurarse de que existen políticas documentadas para gobernar la configuración de contraseñas para los sistemas de TI. Querría asegurarse de que el sistema que se está probando también tenga la capacidad admitir contraseñas alfanuméricas. Si no hay políticas corporativas que requieran contraseñas alfanuméricas, o si el sistema no puede admitir contraseñas alfanuméricas, entonces el control no está diseñado correctamente porque fallará cuando intentes probar la efectividad operativa. La prueba de diseño se puede realizar utilizando varios métodos para que podamos concluir sobre la idoneidad del diseño. Y vamos a repasar eso en la siguiente diapositiva. La prueba de efectividad operativa viene después de la prueba de diseño. Y se utiliza para determinar si el control está funcionando como se pretendía cuando fue diseñado. Yendo con el ejemplo de los controles de contraseña. Para probar la efectividad operativa de ese control, obtendríamos la configuración de contraseña del sistema auditado y nos aseguraríamos de que la configuración, la los ajustes de configuración requieren contraseñas alfanuméricas de los usuarios. Mostrar que la configuración está habilitada será la evidencia de que el control de contraseñas alfanuméricas está operando de manera efectiva. También hay varios métodos que se pueden utilizar para realizar pruebas de efectividad operativa. Y también repasaremos eso en la siguiente diapositiva. Antes de concluir esta diapositiva, hay ciertas cosas que debemos considerar cuando estamos realizando una prueba de efectividad operativa. Hay que considerar la naturaleza del control. ¿Es un control automatizado o es manual? Esto impactará en el tipo de evidencia que necesita revisar para realizar las pruebas. También hay que considerar la frecuencia de la operación. ¿Con qué frecuencia se realiza el control? Esto impactará en el tamaño de selección que necesitas hacer para probar. Y también hay que considerar la significación del control y el riesgo de fracaso. ¿Qué tan importante es este control? ¿Qué tan clave es un control clave? ¿Y es propenso al fracaso? Esto también impactará en los tamaños de selección que realice cuando esté probando este control en particular. Repasaremos los tamaños de selección en una conferencia diferente. En general, todos estos artículos ayudarán a determinar cómo diseñas la prueba a realizar y cómo haces la selección de los artículos que probarás. A continuación, hablemos de técnicas de prueba. En la diapositiva anterior, mencioné que existen diversos métodos para realizar pruebas de diseño y probar la efectividad operativa. Aquí hay algunas técnicas y métodos para las pruebas de diseño que normalmente realizarían indagación. Primero, que es lo mismo hacer preguntas a la gente mediante una entrevista. Inspeccionamos documentos y luego también observamos procesos. Hay que usar al menos dos de estos métodos para las pruebas de diseño, porque la consulta por sí sola nunca es suficiente para las pruebas de diseño. En los casos en que sea absolutamente imposible inspeccionar pruebas u procesos observados, podría ser aceptable realizar lo que se llama una investigación colaborativa, que significa preguntar a dos o más personas el mismo conjunto de preguntas de entrevista para determinar si sus respuestas respecto al proceso y control son las mismas. Para probar la efectividad operativa, puede utilizar las técnicas enumeradas aquí. Pasemos por cada uno. Observación significa que se puede observar que ocurre un proceso para asegurarse de que el control se realiza como parte de ese proceso. Un ejemplo sería observar a alguien usando su placa. Para acceder a la sala de servidores, para probar el control de que el acceso a la sala de servidores está restringido por el acceso de credencial. Inspección significa que usted revisa las pruebas que se le proporcionan para determinar si el control está operando de manera efectiva. Por ejemplo, veamos el control de acceso a la sala de servidores. Puede solicitar y obtener un informe del sistema por lotes para determinar si solo las personas aprobadas tienen los permisos de la sala de servidores en sus insignias. Quieres asegurarte de que todo el mundo no tenga los permisos de la sala de servidores traídos en su credencial. Y eso está restringido solo a individuos que necesitan acceder al servidor. Re-performance significa que estás realizando el control nuevamente para determinar si llegas a la misma conclusión que el control originalmente realizado. Un ejemplo aquí sería, por ejemplo , un. control de reconciliación, donde concilia los mismos elementos en el proceso y vea si obtiene los mismos resultados. Recalculación significa que se calculan los artículos desde el controlador nuevamente para determinar si se le ocurre el mismo resultado. ejemplo, si se supone que el control calcula dos números en cuentas diferentes para la conciliación, puede recalcular manualmente esos números para asegurarse de que los números que usamos la reconciliación donde Correcto. El último ítem que tenemos aquí es una consulta del sistema. Esto significa que puede ejecutar informes desde el sistema para ver los nuevos usuarios que se crean, los cambios realizados en un campo u otros informes aplicables que se pueden utilizar para las pruebas de control. ejemplo, si desea probar el proceso de aprobación para nuevos usuarios, puede ejecutar un informe desde el sistema de todas las cuentas de usuario nuevas que se crearon. Entonces puedes usar esa lista para hacer una selección que luego probarías para determinar si cada usuario tenía un formulario de solicitud de acceso completado y debidamente aprobado por su gerente. Entonces esto en realidad tiene dos elementos. El ejemplo que acabo de usar, usa la consulta del sistema para generar un informe que pueda usar para la selección. Y luego, cuando obtenga sus pruebas para la selección, podrá utilizar la inspección para realizar una prueba para asegurarse de que se cumplieron todos los elementos del control. Con esto concluye la conferencia sobre técnicas de prueba. Vamos a entrar en los tamaños de selección. Bienvenido a la conferencia sobre Tamaños de selección. En esta conferencia, cubriremos el concepto de selecciones. Este concepto se basa en el hecho de que al realizar pruebas de control, suele haber muchos artículos que son comprobables, pero no es práctico probarlo todo. Como tal. Solo muestra de artículos que son elegibles para pruebas, ¿te hacen la prueba? Entonces comencemos con ¿qué es una selección? En pocas palabras, según el diccionario, acilación es una colección cuidadosamente elegida o representativa de personas o cosas, en este caso, elementos o pruebas para pruebas. ¿Por qué hacemos selecciones? Como se señaló anteriormente, es simplemente porque no es factible mirar a toda una población. Hablemos a través de un ejemplo. Por lo que tenemos un control sobre la obtención la aprobación del supervisor antes de otorgar acceso a los usuarios. La prueba de efectividad operativa consiste en verificar los nuevos usuarios creados y asegurarse de que se otorgó la aprobación para cada usuario. Para identificar a los nuevos usuarios, ejecutaríamos una consulta del sistema, como discutimos anteriormente, para determinar el número de nuevos usuarios que se crearon durante el periodo de auditoría. Y para una organización grande, esto puede ser fácilmente de cientos. Entonces esto podría ser un centenar de individuos. Si el número de nuevas contrataciones es digamos, 200, 300, 500, no es factible ni siquiera razonable probar a todos esos usuarios. En este caso, será más práctico hacer una selección representativa de esos usuarios y probarlos. Al probar una muestra representativa de usuarios, podemos entonces extrapolar la conclusión de las pruebas para la selección al resto de la población. Al seleccionar muestras, hay que considerar la frecuencia con la que se realiza el control y el riesgo de falla. Esto le ayuda a determinar cuál debe ser una selección apropiada del tamaño de la muestra. La mayoría de las organizaciones tienen una guía de tamaño de muestra que brinda orientación y el número de muestras a seleccionar en función de la frecuencia del control y el riesgo de falla. Y te mostraré una guía de muestra en la siguiente diapositiva. Por último, también hay que considerar el rango de variables en la población. Lo que esto significa es que debes tratar de cubrir todo el periodo de auditoría en tu selección de muestra. Por lo que cubre todo el rango de variables. ejemplo, si su período de auditoría es de enero a diciembre, quiere asegurarse de seleccionar muestras que corten a lo largo de todo el año, lugar de tener muestras que están sesgadas hacia solo algunas meses del año. Por lo que esto significa que selección del tamaño de la muestra no es del todo aleatoria porque tiene que ser una muestra representativa de toda la población de ítems. Veamos una guía de muestra de tamaños de selección. En esta guía en particular, verías aquí que la frecuencia de control está en la columna izquierda. Y entonces se tiene el riesgo de fracasar a la derecha dos columnas más bajas y superiores. Entonces, lo que esto representa es que para cada frecuencia de control, si se basa en el riesgo de falla, si es un menor riesgo de falla o mayor riesgo de falla, llega a seleccionar cuál el número de artículos que probarías. Veamos semanalmente, por ejemplo, para un control que ocurre semanalmente, si tiene un menor riesgo de falla, solo necesita seleccionar cinco elementos para probar según esta guía en particular. No obstante, si tiene un mayor riesgo de fracaso, entonces querrías probar al menos ocho. Estos números son solo mínimos. Se pueden probar al menos cinco en el extremo inferior del riesgo de falla, u ocho en el extremo superior del riesgo de falla. No es decir que el máximo es solo el número mínimo de artículos que deben probarse para dar comodidad a que se haya probado una muestra representativa. Consulta con tu organización para ver si tienen un gráfico similar cada vez que estés realizando pruebas. Una cosa a tener en cuenta es que si la naturaleza del control es esporádica y la frecuencia de control no se puede identificar claramente. Se debe determinar la frecuencia utilizando toda la población. Si la población es de 12 ítems en total, entonces puedes usar la frecuencia de Motley. O si tienes alrededor de 52 artículos sobre la población, quieres usar la frecuencia de semanalmente. Sin embargo, si la población se encuentra entre dos frecuencias de control definidas anteriormente, utilice siempre la frecuencia más alta. Entonces, por ejemplo, si tienes 25 artículos, entonces no quieres usar mensualmente. Quieres usar semanalmente porque vas a esa siguiente frecuencia de control en el gráfico. Muy bien, hemos llegado al final de esta sección. Repasemos los artículos que hemos aprendido. Aprendimos por qué probamos los controles. Se discutieron los tipos de controles que probamos, los tipos de pruebas que se realizan y luego cómo hacer selecciones para las pruebas. 4. 4. Gracias: Muchas gracias por tomar este curso, y espero que encuentren son los objetivos del curso se han cumplido, debiste haber aprendido los fundamentos de la auditoría de TI. Si tienes alguna duda, por favor no dudes en contactarme. Gracias.