The Audit

An audit is one visit to one unit, against one question list, by one team. It is planned under a programme, carried out by answering its checklist, and closed once whatever it turned up has been dealt with.

Two ways in

	Planned	Unplanned
Opened from	The audits screen	The unplanned-audit screen
Needs	Plan on the programme	Create unplanned on the programme
Starts in	Draft, then Planned	Draft, then straight into fieldwork

A planned audit is scheduled now and carried out later, so it sits in Planned until someone starts it. An unplanned audit is being carried out because something happened, so its screen plans and starts it in one step — there is no useful moment between the two.

Both end up as the same record. Which route it came by is kept, because an audit programme's year looks different depending on how much of it was planned.

The lifecycle

Draft ──Plan──▶ Planned ──Start──▶ In Progress ──Complete fieldwork──▶ Closure Approval
  │                 │                                                    │        │
  │                 │                                           Close ───┘        └─── Close and track
  │                 │                                             │                          │
  └──Cancel─────────┴──Cancel──▶ Cancelled                        ▼                          ▼
                                     │                          Closed  ◀───────────  Awaiting Action
                                     └──Replan──▶ Planned                 (last record settles)

Draft

The audit exists but has not been committed to. Plan schedules it; Start (on the unplanned screen) opens it straight into fieldwork; Cancel drops it.

Planned

Scheduled. The team, the dates and the question list can still be changed. Start begins the fieldwork.

Cancel is still available here — nothing has been recorded yet.

In Progress

The audit is being carried out. The lead auditor holds a task for it. This is where the checklist is answered and findings are raised.

note

Cancel disappears from here on. By now there are answers on the record and findings other people can already see — some of them with corrective records opened against them. Abandoning the audit would throw away work that is no longer only the auditor's.

Complete fieldwork sends it on for closure approval.

Closure Approval

The audit is finished in the field and the lead auditor is deciding how to close it. Three exits, side by side in this order:

• Close and track — close the fieldwork but keep the audit open against the records its findings asked for, until those records settle.
• Close — close the audit now.
• Close with justification — close the audit now even though its findings would otherwise hold it, with a written reason. See Closing with a justification.

Close and Close and track do the same thing first: they open everything the findings have declared and not yet had opened. The difference is only whether the audit then waits for them.

Before either is allowed, the findings are checked. A finding whose type obliges a corrective record, that has not declared one, blocks the audit — and the findings grid says which, and why, rather than leaving the auditor to guess from a one-line refusal.

Close is held back by one more thing. A finding whose type blocks closure must not be left with a DİF or action still open — and Close would open the records it declared and walk away from them in the same step. In that case Close is refused: use Close and track to wait for those records, or Close with justification to close past them.

note

This state is also re-entered by the system, not only by a button. An audit that went to Awaiting Action comes back here once the last of its records settles, so that whoever closes it does so looking at the same screen, with the same two choices, as the first time.

Awaiting Action

Nothing to press. The audit is waiting on the records its findings opened — the DİFs in the CAPA module and the actions under the findings themselves.

When the last of them settles, the audit returns to Closure Approval on its own.

note

An audit only stands here while something is actually owed. If the approval opened nothing — because the findings asked for nothing — the audit walks straight on to Closed rather than waiting on a step that no task and no person would ever raise.

Closed

Finished. The record is readable and nothing more is expected of it.

Cancelled

Dropped before fieldwork. A cancelled audit is not deleted — the plan it came from is part of the programme's history — and Replan puts it back into Planned if it turns out to be wanted after all.

The record

Identity and scope

• Code — issued from the code template, or typed.
• Name.
• Programme — the register this audit belongs to, and the thing that decides who may touch it.
• Audit type — see Audit types. Decides the category (internal / external / supplier), what findings may oblige, and which question lists are offered.
• Audited organization unit — who is being audited. A finding raised here answers to this unit by default.
• Unplanned — whether it came in by the unplanned route.

Dates

• Planned start / planned end — when it is meant to happen. The planned end cannot precede the planned start, and the screen enforces that live rather than at save.
• Actual start / actual end — stamped by the state machine, not typed.

People

• Lead auditor — must be on the auditor register. Holds the audit's tasks, and is who the audit is addressed to at each step.
• Team members — the rest of the team, each with a competence level for this audit. Whether a member may answer the checklist is decided by that level, not by the person.

The checklist

• Checklist template — the question list to use. See Scoring.
• Schema — the audit's own copy of the questions, taken when the template was chosen.
• Answers, and who saved them, and when.
• Score — earned, maximum and percentage. Calculated by the server from the answers; never typed.

What it turned up

• Findings — see Findings.
• Record counts — how many DİFs and actions this audit opened, and how many of those are still outstanding. Recalculated on every save, which is what lets the audit know when it may leave Awaiting Action.
• Attachments — the audit's own papers: the notice, the opening and closing minutes. The audit report and the closing summary are not attachments; see The audit report.

note

Evidence against a single question is not an audit attachment. The checklist carries its own file question, and a file answered there stays with the answer it belongs to.

The audit report

The report is produced by the system from the audit itself — nobody writes it, and nobody can edit it.

• Draft report — available on the perform page before the closure is approved, and again in Closure Approval when the audit comes back to it for another round. It shows the report as it would read now, with Draft printed on it. It is generated each time it is asked for and is not kept.
• Audit report — the issued report. It is published the moment the closure is approved (Close, Close and track, or Close with justification) and does not change on its own: later edits to a finding, or a record closing in the CAPA module, are not written back into it. When the audit comes back to Closure Approval and is approved again — a round in which findings may have been added — the report is published again: the new report replaces the previous one, and the publication date becomes that approval's date.
• Closing summary — what became of every finding: each DİF and action it opened, with code, responsible, due date and closing date. It is produced when the audit reaches Closed; an audit that waits in Awaiting Action gets it when it finally closes. An early close prints its justification on it.

The report contains the audit's identity, programme, type and audited unit, the planned and actual dates, the team and their roles, the scope (taken from the audit type's and the audit's own name and description), the score and how many questions were answered "not applicable", a count of findings by type, the findings themselves, the related records — every DİF and action the findings asked for, with its title, detail, responsible, due date and status (declared in the draft; with its code once the approval has opened it) — and every question with its answer and note as an appendix.

Both issued documents are downloaded from the audit screen, not from the attachments panel, and only by someone who may see the audit under its programme. Both are printed from Excel templates — the audit type's own if it has one, otherwise the one on the module's settings screen, otherwise the built-in one; the form number, revision and logo are part of the template. See Settings.

note

The Report published date on the audit is what the analysis counts as the audit being realised.

Closing with a justification

Sometimes an audit has to be closed while a finding would normally block it — a finding that obliges a corrective record and has not declared one, for instance. Close with justification is for that, and only in Closure Approval.

It asks for a justification (required), then closes the audit straight away:

• the findings check that would stop an ordinary close is not applied;
• anything the findings did declare is still opened, exactly as on an ordinary close;
• the audit does not wait in Awaiting Action — it goes directly to Closed, and the opened records carry on in their own flows;
• the justification is kept in the audit's history, shown on the audit's view screen and printed on the closing summary;
• when it is done you are taken back to where you opened the audit from, as with an ordinary close.

It needs the same permission as editing the audit.

Related

• Audit programmes
• Scoring
• Findings
• Analysis