Beginner question: what does AuditBoard actually do during an audit?

As someone who works in SRE and observability, I often think about audit processes through the lens of evidence collection, traceability, and state verification. When a colleague recently asked me to explain AuditBoard's role in a financial or SOX audit, I found it helpful to break it down into its core operational functions, much like I would a monitoring system. It is fundamentally a platform designed to manage the entire lifecycle of an audit, with a heavy emphasis on workflow, documentation, and risk assessment. From my research and discussions with auditors who use it, its primary activities during an audit can be categorized into several key areas.

First, it serves as the centralized repository for all audit-related documentation. This is analogous to a single source of truth in a Kubernetes cluster, like a well-managed GitOps repository.

* **Workflow Management:** It guides the audit team through a predefined, but often configurable, sequence of tasks. This includes assigning control tests to specific team members, setting due dates, and tracking completion status. The system enforces a progression through stages like "Planned," "In Progress," "Under Review," and "Completed."
* **Evidence Request and Collection (often called "Request Lists"):** Auditors use the platform to formally request evidence from control owners (e.g., system administrators, finance personnel). These requests are tracked within the system, with reminders and escalation paths. The control owners upload files, screenshots, or data directly into the platform, linking them to the specific control or request.
* **Testing and Evaluation:** The platform provides structured forms for auditors to record their testing procedures, results, and conclusions. For example, a test of a user access review control might involve the auditor sampling a set of users in the system and documenting whether the appropriate manager approved their access. The findings, including any exceptions or deficiencies, are logged directly against the control within AuditBoard.

Second, and crucially, it manages the findings and remediation process. This is similar to tracking incidents and post-mortem actions in an SRE context.

* **Issue Tracking:** Any control failure or deficiency identified during testing is logged as a formal "issue" or "finding." The platform tracks the severity, root cause, and required remediation actions.
* **Remediation Workflow:** It assigns remediation tasks to process owners, with due dates and requires them to upload evidence that the fix has been implemented. The auditor then re-tests the control to verify the remediation is effective before closing the issue.

Finally, it provides real-time reporting and visibility. This is the observability piece.

* **Dashboarding:** Audit committees and management can view dashboards that show overall audit status, open issues, testing progress, and risk assessments. This moves the process away from periodic email updates to a live, status-of-the-system view.
* **Automated Workpaper Generation:** A significant manual effort in traditional audits is compiling final workpapers. AuditBoard can automatically generate formatted PDF workpapers from the entered data, evidence, and conclusions, ensuring the final deliverable is consistent and traceable.

To make this concrete, consider a simplified example of auditing a hypothetical infrastructure control: "All production Kubernetes namespace creations must be approved via a Terraform merge request in Git and logged." In AuditBoard, the auditor would:

1. Be assigned the test for this control.
2. Use the platform to send a request to the platform team for a sample of namespace creation logs from the logging system (e.g., Loki or Elasticsearch) and the corresponding Git repository merge request logs.
3. Receive and store the exported CSV files and GitLab screenshots directly in the AuditBoard request.
4. Perform the test within the platform, documenting the sample selected and comparing the timestamps and approval IDs between the two evidence sources.
5. Document the pass/fail result. If a namespace was created without a merge request, they would log a finding, assign it to the platform engineering lead, and track the remediation (e.g., fixing the deployment pipeline and adding a guardrail) through to closure.

In essence, AuditBoard doesn't "do" the audit itself; it provides the structured framework, evidence tracking, and workflow automation that orchestrates the human auditors' activities, ensuring completeness, consistency, and audit trail integrity. It replaces shared drives, email threads, and manually assembled spreadsheets with a purpose-built, auditable system of record.