Planning and Designing Technical Audits

1. Defining the scope of an audit.


The scope of a technical audit refers to the specific boundaries of what will be examined during the audit process. It defines the systems, processes, locations, and time periods that will be covered during the audit. In other words, it describes what is “in” the audit and what is “out.”

Determining the appropriate scope is crucial for the success of an audit, as it allows auditors to focus on the most relevant and critical aspects of the system or process under review. Factors that determine the scope of an audit include:

  1. Audit objectives: Here, the purpose and specific goals of the audit are defined. Thus, the objectives can vary from ensuring regulatory compliance to assessing the effectiveness of internal controls or identifying areas for improvement in operational efficiency.
  2. Risks and materiality: It is essential to carry out the identification of relevant risks and their impact on the organization to help prioritize the audit areas of focus. Materiality refers to the threshold at which an error or discrepancy can be considered significant. Thus, these two factors are crucial in guiding auditors in selecting areas that require more attention and analysis.
  3. Size and complexity of the organization: Obviously, the organizational structure, volume of transactions, and diversity of operations influence the scope of the audit. Thus, a larger and more complex organization will require a broader scope and a more detailed approach.
  4. Competence and resources of the audit team: It must be taken into account that the experience and skills of the audit team, as well as the available resources, affect the scope of the audit. Thus, it is essential that the team has the capability to adequately address the selected focus areas.
  5. Time and budget: As is obvious, the duration and financial resources allocated to an audit can also affect its scope, as time and budget constraints may require scaling back the scope or selecting priority areas to focus on.

The basic elements for establishing the scope of an audit include:

  1. Defining the audit objectives.
  2. Identifying risks and assessing materiality.
  3. Setting the focus areas and audit procedures.
  4. Determining the size and composition of the audit team.
  5. Establishing a schedule and budget for the audit.

Regarding the vagueness or error in establishing the previously seen factors, it can have very negative consequences for the success of an audit. Thus, a poorly defined or too broad scope can lead to a dispersed focus, which may result in insufficient analysis of critical areas or the omission of significant risks, while a too narrow scope may limit the auditors’ ability to identify issues and areas for improvement within the organization. Additionally, it should be considered that a poorly defined scope can cause delays in the audit and inefficient use of resources. Therefore, it is crucial to establish an appropriate and realistic scope that allows auditors to perform a thorough and effective review of the processes and systems in question.


2. Audit plan.


The Audit Plan is a key document that details the approach, objectives, scope, schedule, and resources needed to carry out an audit, and, therefore, is essential for ensuring the audit’s success for several reasons:


  1. It sets clear objectives: A well-defined Audit Plan sets clear and specific objectives, which helps auditors to focus on key areas and stay aligned with the audit goals.
  2. It defines the scope: The Audit Plan is essential for establishing and delimiting the audit’s scope, ensuring that auditors focus on the relevant and critical areas for the organization, avoiding inefficient use of resources and time.
  3. It identifies risks and materiality: A good Audit Plan includes the identification of risks and the assessment of materiality, allowing auditors to prioritize areas that require more attention and analysis.
  4. Resource allocation: The Audit Plan provides information on the necessary resources, both human and financial, to carry out the audit efficiently and effectively.
  5. Schedule and logistics: A well-structured Audit Plan includes a detailed schedule, which allows auditors and the organization to plan and coordinate the audit appropriately, ensuring that deadlines are met and disruptions to normal operations are minimized.
  6. Communication and coordination: The Audit Plan serves as a means of communication between auditors, the audited organization, and, in some cases, regulators or third parties interested. It facilitates coordination and mutual understanding of expectations, responsibilities, and audit outcomes.

The relationship between the Audit Plan and the audit scope is direct, as the plan establishes the scope and focus areas for the audit. A well-developed and executed plan contributes to the audit’s success, while a poor or poorly executed plan can result in an inadequate scope and, therefore, the audit’s failure.

The Audit Plan should resolve and/or avoid the following issues:

  1. Lack of clarity in the objectives and scope of the audit.
  2. Deviations from the objectives and scope during the audit.
  3. Inefficient use of resources and time.
  4. Omission of significant risks or critical areas.
  5. Lack of communication and coordination among stakeholders.
  6. Non-compliance with deadlines and expectations.

In conclusion, we can say that a solid and well-executed Audit Plan is fundamental to ensuring the success of an audit, as it provides clarity, focus, and coordination throughout the audit process.


3. Audit approach.


In the context of a company (for example) that has recently launched a web application marketplace for a prominent bookstore chain, a dual audit strategy is proposed. The application facilitates both electronic transactions through a payment gateway and inventory and order management.

The challenge is to describe two differentiated audit methodologies based on the audit team’s prior knowledge of the system: one within the framework of “black box” testing and the other under the “white box” approach, or following ISECOM terminology, “glass box”. For each approach, the scope, client objectives, and required technical resources will be defined, emphasizing the distinctions between them.

  1. Audit 1: “Black Box” Perspective
    1. Client Objective: The client seeks to ensure that the web application is secure, functional, and offers adequate performance from the perspective of an end-user or a potential attacker, without taking into account the details of internal implementation.
    2. Technical Resources and Environments Required: The audit team will need access to the web application in a testing environment similar to the production environment. They can use security scanning tools and automated tests, as well as conduct manual tests to assess the functionality and performance of the application. They will not have access to the source code or detailed information about the system’s architecture.
    3. Scope: The “Black Box” audit focuses on assessing the security, functionality, and performance of the web application without knowing specific details of the source code, internal architecture, or technical implementation of the system. The approach is similar to that of an external user or attacker attempting to identify vulnerabilities and failures in the application.

In a “Black Box” or black box audit, the audit team could conduct the following tests and analyses:

  1. SQL Injection Testing: The auditor could attempt to inject malicious SQL code into the web application’s input fields to identify SQL injection vulnerabilities. If successful, this could allow an attacker to access the database and compromise stored information.
  2. Authentication and Authorization Testing: The auditor could test the robustness of the application’s authentication and authorization mechanisms, attempting, for example, to bypass authentication using brute force attacks or manipulating session cookies.
  3. Payment Gateway Security Testing: The auditor could assess whether the payment gateway is properly protected and whether industry security requirements, such as the PCI DSS standard, are met.
  4. Performance and Load Testing: The auditor could subject the web application to high traffic loads and simultaneous users to assess how the system behaves under high demand, identifying potential bottlenecks or performance failures.
  1. Audit 2: “White Box” Perspective
    1. Scope: The “White Box” or glass box audit involves a thorough analysis of the web application, including access to and review of the source code, the system’s architecture, and technical implementation. The focus is to assess the security, functionality, performance, and code quality from the perspective of a developer or internal security expert.
    2. Client Objective: The client seeks a detailed evaluation of the web application that identifies potential vulnerabilities, performance issues, and functional failures from an internal technical perspective, with the aim of improving code quality and ensuring the security and effectiveness of the application.
    3. Technical Resources and Environments Required: The audit team will need full access to the source code, the system’s architecture, and technical documentation. They will also require access to a testing environment where they can analyze and test the code. They can use static and dynamic code analysis tools, as well as conduct manual tests and code reviews to assess the quality, security, and performance of the application.

In a “White Box” or glass box audit, unlike the black box audit, the audit team could conduct the following tests and analyses:

  1. Static Code Analysis: The auditor could review the application’s source code for vulnerabilities, such as the use of insecure functions, lack of data input validation, or exposure of confidential information in the code, among others.
  2. System Architecture Review: The auditor could analyze the system’s architecture, including the interaction between components, communication between servers, and data management, to identify potential weaknesses or vulnerabilities in the design.
  3. Session and Cookie Management Analysis: The auditor could review the source code and implementation of session and cookie management to ensure that security best practices are followed and user data is adequately protected.
  4. Security Testing in Payment Gateway Integration: The auditor could evaluate the source code and technical implementation of integration with the payment gateway to ensure that industry security requirements, such as the PCI DSS standard, are met, and that security best practices in the transmission and storage of sensitive data are applied.

At this point, we can say that the key differences between the two audits lie in the level of knowledge the audit team must have and in access to the web application. Thus:

  1. The “Black Box” audit focuses on the system’s external perspective, without access to internal implementation details, as it focuses on external tests and interaction with the application.
  2. The “White Box” audit involves a detailed and deep approach, with full access to the system’s internal information, as it analyzes the source code and internal architecture of the system, providing a more detailed and complete view of the application’s security and quality.

4. Planning a technical audit.


Planning a technical audit for a company as described in the previous point involves a detailed and multifaceted strategy that spans from the initial conception to the conclusion of the project. It is proposed that the company opts to outsource an audit focused on verifying the application of technical controls over communication networks. This approach includes a thorough analysis of WiFi networks, segmentation, and traffic filtering in the network and transport layers of the TCP/IP protocol suite, as well as a careful inspection of interconnection points with other networks, point-to-point or VPN connections with third parties, and access protection at the network interface layer.

As the lead auditor of the “contracted auditing firm,” I could present the following comprehensive project planning for the technical audit, consisting of several phases from the kickoff meeting to the project’s completion:

Phase 1: Kickoff Meeting and Scope Definition.

  1. Objective: Establish a common understanding of the audit’s scope and objectives, introduce project participants, and define their roles and responsibilities.
  2. Activities:
    1. Introduction of project participants and their roles.
    2. Review and discussion of the audit’s scope.
    3. Identification of the audit objectives.
    4. Review of resources and access needed to carry out the audit.

Phase 2: Information Gathering and Risk Analysis.

  1. Objective: Obtain relevant information about the network infrastructure, connections with third parties, and network segmentation, as well as identify potential risks associated with these elements.
  2. Activities:
    1. Collection of technical documentation, policies, and procedures related to the network.
    2. Interviews with technical and security staff to gather additional information.
    3. Risk analysis and assessment of the effectiveness of existing controls.

Phase 3: Planning and Execution of Tests.

  1. Objective: Design and carry out audit tests to evaluate the effectiveness of technical controls over communication networks, segmentation and traffic filtering, and connections with third-party networks.
  2. Activities:
    1. Design of specific audit tests and evaluation methodologies.
    2. Execution of audit tests in testing and production environments, as appropriate.
    3. Documentation of test results and findings.

Phase 4: Results Analysis and Report Preparation.

  1. Objective: Analyze the results of the audit tests and prepare a detailed report presenting the findings, identified deficiencies, and recommendations for improving network security.
  2. Activities:
    1. Analysis of audit test results.
    2. Identification of deficiencies and areas for improvement.
    3. Development of improvement recommendations.
    4. Drafting of the audit report.

Phase 5: Presentation of Results and Follow-Up.

  1. Objective: Present the audit results to the Security Committee and the Internal Review Officer, and establish a follow-up plan to ensure that the improvement recommendations are implemented.
  2. Activities:
    1. Presentation of audit results and discussion of findings and recommendations.
    2. Establishment of a follow-up plan and assignment of responsibilities for implementing improvement recommendations.
    3. Monitoring and follow-up on the progress of implementing the recommendations.

Activity schedule:

Below is an activity schedule for the audit project.

Week 1:

  1. Day 1: Kickoff meeting and scope definition.
  2. Day 2-5: Identification of contact points and initial documentation gathering.

Week 2:

  1. Day 1-3: Review of technical documentation, policies, and procedures.
  2. Day 4-5: Interviews with technical and security personnel.

Week 3:

  1. Day 1-5: Risk analysis and preliminary evaluation of existing controls.

Week 4:

  1. Day 1-3: Design of specific audit tests and evaluation methodologies.
  2. Day 4-5: Setup of testing environments and preparation of audit tools.

Weeks 5 and 6 (Audit Execution):

  1. Day 1-5: Execution of audit tests in testing (PRE or QA) and production (PRO) environments, as appropriate.
  2. Day 6-7: Weekend break.
  3. Day 8-13: Continuation of audit tests in testing (PRE or QA) and production (PRO) environments, as appropriate.

Weeks 7 and 8 (Audit Report Preparation):

  1. Day 1-3: Documentation of test results and findings based on evidence.
  2. Day 4-5: Analysis of audit test results and classification of findings.
  3. Day 6-7: Weekend break.
  4. Day 8-9: Identification of deficiencies and areas for improvement.
  5. Day 10: Development of improvement recommendations.
  6. Day 11-13: Drafting of the audit report.

Week 9:

  1. Day 1-2: Internal review of the audit report and final adjustments.
  2. Day 3: Submission of the audit report to the client for review.
  3. Day 4-5: Meeting to discuss the findings and recommendations of the audit report.

Week 10:

  1. Day 1-5: Review of client comments and adjustments to the audit report, as necessary.

Week 11:

  1. Day 1: Final presentation of the audit results to the Security Committee and the Internal Review Officer.
  2. Day 2-5: Establishment of a follow-up plan and assignment of responsibilities for the implementation of improvement recommendations.

Week 12:

  1. Monitoring and tracking the progress in implementing the recommendations. It is advised to conduct this monitoring and follow-up on a quarterly basis.

To carry out the corresponding certification processes, it is essential to conduct good prior audit planning, as we show in our article “Principles, Program, and Planning of Audit and ICT Governance“.

If you need an audit plan, you can contact us through our contact form.

Spain

No puedes copiar el contenido