How an audit is created, and what happens next¶
There are four ways an audit comes into existence, and they behave differently once created. A caller saying "the audit is wrong" usually needs a different answer depending on which of the four produced it.
The four routes in¶
1. Requested in the UI¶
Request New Audit on the module screen. Someone picks the application, the audit type,
the category and the cycle, and the audit is created in Saved.
This is the only route where all the properties are chosen deliberately, which is why audits created this way have complete Audit Properties chips and imported ones often do not.
Every field on the request form, and what choosing it decides¶
The form has three parts: the first narrows what is being assessed, the second defines how, the third says who.
Context — each choice filters the next, so working top to bottom is faster than it looks:
| Field | What choosing it decides |
|---|---|
| Org | The organisation the audit belongs to. Everything below is filtered to it |
| Application Type | Web, mobile, thick client and so on. It filters the application list, and it decides which audit properties become mandatory further down |
| Business Unit, Projects | Narrow the application list further. They change what you can pick, not the audit itself |
| Application Name | Required. The asset being assessed. Decommissioned applications are deliberately not offered |
Audit definition — the choices that change how the audit behaves afterwards:
| Field | What choosing it decides |
|---|---|
| Methodology | Required. Black box, grey box or white box — how much the tester was given. It bounds what the assessment could have found, which is the first thing an auditor asks about a result |
| Audit Type | Required. Your organisation's own list, administered under Configurations |
| Audit Cycle | Required. A scheduled round or a one-off — and it decides which Audit Scope values are offered. An ad-hoc audit may be scoped freely; a calendar-cycle audit is held to the full scope. A scope you expected can be missing simply because of the cycle chosen above it |
| Audit Scope | Required. Full or partial coverage. Partial scope is why "we tested that" can be true and still not cover the thing being asked about |
| Audit Category | Required. The classification the audit is reported under |
| Scope Length | How much was assessed — screens, endpoints or modules in scope. It is what makes two audits comparable when one covered four screens and the other forty |
| URL | The address assessed. On a multi-URL application this is the one this audit covers, not the whole application |
| Audit Name | Free text. On a re-test it arrives pre-filled with Confirmatory and the parent's identifier |
| Start Date, Closure Date | Planned dates. The closure date is a plan — not the date the audit counts from, which is when it reaches a final state |
| Audit properties | Your own fields, defined under Configurations. Which are mandatory depends on the asset type and audit type together, which is why two audits can demand different fields |
| Remarks | Free text carried with the audit |
| Upload Documents | Scope documents, authorisation, rules of engagement — attached here they stay with the audit |
Assignment:
| Field | What choosing it decides |
|---|---|
| Auditor | Who works the audit. It can be left empty, and that is the commonest reason an approved audit sits with nothing happening |
| Comment | Sent to the approver with the request |
2. Imported in bulk¶
A file of audits, staged and queued like any other import. Used when onboarding a programme of work that already exists elsewhere — a year of assessments being migrated in.
Two consequences:
- Properties absent from the file are absent from the audit. A blank cycle or category chip usually means the column was not in the import, not that someone forgot to set it.
- Import is asynchronous. Audits appear when the worker processes the batch, not when the upload returns.
3. Created by a tool integration¶
Some integrations create an audit for each scan they find. A Burp Suite scan, for instance, becomes an audit against the application it targeted.
This is the route that surprises people: audits appear that nobody created. That is the integration doing its job. The audit is named after the scan, and its properties come from what the tool knew, which is usually less than a person would have entered.
If a module fills with audits after an integration is connected, this is why — and the fix is scoping what the integration collects, not deleting audits.
4. As a re-test of an earlier audit¶
A confirmatory audit is created against a parent audit to verify that fixes hold. The form opens pre-filled — the name as Confirmatory plus the parent's identifier, and the start date as today — both of which you can change before saving. Naming that parent is what makes the audit's chip read Confirmatory rather than Initial, and it inherits the parent's scope.
The chain matters for reporting: a confirmatory audit is evidence about the original, not an independent assessment, and the two should not be counted as two rounds of testing.
What "considered" decides¶
Only one audit per asset should normally count towards the organisation's figures — the
latest one that reached a final state. That is what Considered marks.
A considered audit is chosen, not automatic
An audit only becomes considered when it reaches a final state, and the date it did so is the date aggregate views use for it — not the date it was created, and not the date the scan ran.
So a scan run in March, imported in April and completed in May counts as May in the dashboards. Support tickets about "findings appearing in the wrong month" are almost always this.
An audit marked Considered — No keeps all its findings and appears in the module, and is excluded from dashboards, posture counts and reports. Superseded audits, trial runs and assessments of decommissioned environments are the normal reasons.
Status, and who can move it¶
An audit moves through its statuses in a defined order, and the dropdown offers only the legal next steps from where it is. An option that is missing is a transition that is not allowed from the current state, or one your role cannot perform — not a defect.
Some transitions require a comment — whether one is needed is a property of the status being moved to, so moving an approved audit to Hold asks for one, and the same is true of any status an administrator has marked as needing a reason. Bulk Approve applies one status change to every selected row, which is the reason the checkbox column exists and the usual tool after a large import.
A reverted audit comes back with its start date cleared
When an audit is sent back with Reverted, reopening it for edit unlocks the fields and blanks the start date deliberately. The audit is being re-run, so the original start date is no longer true, and leaving it in place would silently misstate how long the work took.
Set it again before saving — the form will not accept the audit without it.
Deleting an audit¶
Deletion is soft: the record is hidden rather than destroyed. That is why a deleted audit's name can still appear on historical findings and older reports, and why deleting an audit does not retrospectively change a report already produced.
If an audit was deleted to correct a mistake and its findings are still visible somewhere, that is the design rather than a failure to delete.
What to ask when an audit looks wrong¶
- Which route created it? The chips tell you — a confirmatory chip, or missing properties suggesting an import or an integration.
- Is it considered, and when did it reach a final state? This answers most "wrong period" and "not in the dashboard" questions.
- Is the status where the caller thinks it is? Findings are not counted anywhere until they are approved, regardless of the audit's own status.