> For the complete documentation index, see [llms.txt](https://interfacing.gitbook.io/interfacing-help-files/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://interfacing.gitbook.io/interfacing-help-files/auditors/managing-internal-audits-apps/planning-and-executing-audits.md).
# Planning & Executing Audits
Perform tasks assigned to your role to advance audits through the Audit Planning & Execution workflow.
## Workflow Overview
The **Audit Planning & Execution** workflow governs the planning, scheduling, and execution of audits.
***
## Interactive Tour
Explore the **Audit Planning & Execution** workflow and learn how each stage works, with key guidance and best practices along the way.
{% @howdygo/embed url="" %}
***
## Workflow Initiation
An audit can be initiated through either of the following triggers.
{% tabs %}
{% tab title="Triggered by Audit Plan" %}
A team leader may initiate an audit by creating and submitting an audit plan using the [**New Audit**](/interfacing-help-files/auditors/managing-internal-audits-apps/planning-and-executing-audits/plan-audit.md) form.
This trigger is used for structured, forward-looking audit planning. Audits are defined in advance with a planned timeline and remain inactive until the specified **Actual Start Date** is reached.
On that date, the system automatically progresses the audit to the scheduling stage and assigns the task to the designated team leader.
{% endtab %}
{% tab title="Triggered Ad Hoc" %}
A team leader may initiate an audit on demand by submitting the [**Trigger Ad Hoc Audit**](/interfacing-help-files/auditors/managing-internal-audits-apps/planning-and-executing-audits/trigger-ad-hoc-audit.md) form.
This trigger is used for unplanned or immediate audit needs that fall outside the regular audit schedule. Upon submission, the audit is immediately initiated and progresses directly into execution.
During initiation, the team leader must define participants, assign auditors, and configure the audit schedule to enable immediate execution.
{% endtab %}
{% endtabs %}
***
## Workflow Stages
The workflow is organized into **eight key stages**, each with specific roles and responsibilities.
{% hint style="success" %}
For detailed instructions on any stage, click the corresponding button.
{% endhint %}
{% stepper %}
{% step %}
### Define Audit
> **Performed By:** Assigned Team Leader (e.g., Audit Lead, Audit Supervisor, Engagement Lead)
#### :calendar-range: Planned Audit
Use the **New Audit** form to define and prepare an audit in advance as part of structured audit planning.
**Responsibilities:**
* Identify the need for an audit as part of the audit planning cycle.
* Select and assign one or more audit programs to define the audit scope.
* Establish the audit timeline by defining planned and actual start and end dates.
* Review and configure requirement testing, enabling or disabling testing for applicable requirements.
* Submit the audit plan to initiate the workflow.
#### :rocket-launch: Ad Hoc Audit
Use the **Trigger Ad Hoc Audit** form to define and initiate an audit outside the regular schedule.
**Responsibilities:**
* Identify the need for an immediate or unplanned audit.
* Select and assign one or more audit programs to define the audit scope.
* Define the audit timeline within allowed constraints.
* Assign audit participants.
* Configure the audit schedule.
* Assign auditors to requirements to support execution.
* Review and configure requirement testing, enabling or disabling testing for applicable requirements.
* Submit the audit to initiate the workflow.
{% hint style="danger" %}
This stage is skipped if the audit is initiated ad hoc.
{% endhint %}
***
{% endstep %}
{% step %}
### Assign Auditor(s)
> **Performed By:** Assigned Lead Auditor
**Responsibilities:**
* Assign or update auditors for each requirement.
* Submit auditor assignments for review and confirmation.
{% hint style="danger" %}
This stage is skipped if the audit is initiated ad hoc.
{% endhint %}
***
{% endstep %}
{% step %}
### Assign Collector(s)
> **Performed By:** Assigned Lead Evidence Collector
**Responsibilities:**
* Assign or update evidence collectors for each requirement.
* Define or revise evidence collection dates for each round.
* Submit collector assignments and schedules for review and confirmation.
{% hint style="warning" %}
This stage is triggered only when at least one requirement is included in testing.
{% endhint %}
{% hint style="danger" %}
This stage is skipped if the audit is initiated ad hoc.
{% endhint %}
***
{% endstep %}
{% step %}
### Confirm Schedule
> **Performed By:** Assigned Team Leader (e.g., Audit Lead, Audit Supervisor, Engagement Lead)
**Responsibilities:**
* Review the audit schedule, including timelines, participants, and overall structure.
* Verify that auditor assignments are complete and appropriately distributed across requirements.
* Verify that evidence collector assignments and collection schedules (if applicable) are accurate and feasible.
* Ensure the audit setup is complete, consistent, and aligned with the planned scope.
* Confirm the schedule to proceed with audit execution, or reject it for revision if updates are required.
{% hint style="danger" %}
This stage is skipped if the audit is initiated ad hoc.
{% endhint %}
***
{% endstep %}
{% step %}
### Evaluate Requirements
> **Performed By:** Assigned Auditors
**Responsibilities:**
* Review assigned requirements to assess compliance against defined criteria.
* Complete associated checklists to support requirement validation (if applicable).
* Review, collect, and document evidence to support audit findings.
* Request additional evidence when necessary to complete the evaluation.
* Record observations and findings, including non-conformities or areas for improvement.
* Ensure all assigned requirements are fully evaluated and marked as complete.
* Submit audit results to proceed to the review and approval stage.
If additional evidence is requested from another party, the **Evidence Request** workflow is initiated.
This workflow is organized into **two key stages**:
{% stepper %}
{% step %}
### Request Evidence
> **Performed By:** Assigned Auditors
**Responsibilities**:
* Initiate the evidence request.
* Select a recipient and specify the required evidence.
* Submit the request to initiate the workflow.
***
{% endstep %}
{% endstepper %}
***
{% endstep %}
{% step %}
### Manage Evidence Collection
This stage includes the **Evidence Collection** subprocess, which governs activities required to collect, review, and validate evidence for tests linked to audit requirements.
{% hint style="warning" %}
This stage is triggered only when at least one requirement is included in testing.
{% endhint %}
This workflow is organized into two key stages.
{% stepper %}
{% step %}
### Collect Evidence
> **Performed By:** Assigned Collectors
**Responsibilities:**
* Review assigned tests and evidence requirements, including sample size and collection details.
* Collect and document required evidence samples.
* Provide comments or additional context as needed.
* Ensure all required samples are collected and properly recorded.
* Submit collected evidence for review.
***
{% endstep %}
{% step %}
### Review Evidence
> **Performed By:** Assigned Lead Evidence Collector
**Responsibilities:**
* Review submitted evidence to assess completeness, accuracy, and relevance.
* Evaluate evidence against defined requirements and testing criteria.
* Approve acceptable evidence or reject records that require revision.
* Provide feedback and justification for any rejected evidence.
* Submit the review outcome to either finalize evidence collection or return it for updates.
***
{% endstep %}
{% endstepper %}
***
---
# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.
## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.
Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:
```
GET https://interfacing.gitbook.io/interfacing-help-files/auditors/managing-internal-audits-apps/planning-and-executing-audits.md?ask=&goal=
```
`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
