Skip to main content

Audit Programmes

An audit programme is the register audits are planned in β€” "2026 Internal Audits", "Supplier Audits", "ISO 27001 Certification Cycle". Every audit in the system belongs to exactly one.

It is also the module's gatekeeper, and that is the part worth understanding first.

The programme decides who may do what​

Most modules answer "may this person do this?" with a permission. Audit management answers it with the programme's own authorization matrix.

The reason is that audit work is not organised by job title. The person who plans the internal audit calendar is not the person who opens a supplier audit on the spot, and neither of them should necessarily be able to read the certification body's findings. A single set of permissions cannot express that, because the same people hold different roles in different programmes.

So each programme carries its own matrix: a list of identities, and what each may do here.

GrantWhat it allows
PlanPlan an audit under this programme, from the programme's own screen.
Create unplannedOpen an unplanned audit against this programme, from the unplanned-audit screen.
ViewRead the programme and the audits under it.
UpdateEdit the programme and the audits under it.
DeleteRemove the programme and the audits under it.
note

Plan and Create unplanned are deliberately separate. They are reached from two different screens and mean two different things β€” planning fills a calendar ahead of time, an unplanned audit is opened on the spot because something happened. Someone trusted with the first is not automatically trusted with the second.

An identity in the matrix may be a user, a role, a position, an organization unit or a user group. A person is granted whatever any matching row grants them.

The matrix is sent whole​

Editing the matrix replaces it. A row left out of the save is a row revoked β€” there is no separate "remove" step, because the screen that edits the matrix is the only screen that can revoke anything, and a merge would make revoking impossible from it.

The creator exemption​

Whoever created a programme can always see it, even with no row naming them. Without that, it would be possible to create a programme and immediately lose access to it.

The exemption stops at reading. It does not let the creator plan, update or delete β€” those still need a row.

The record​

  • Code β€” issued from the code template, or typed. Unique.
  • Name and description.
  • Start date / end date β€” the period the programme covers. Audits planned under it are expected to fall inside it; the dates are what the audit's own planning screen uses as its lower bound.
  • Authorizations β€” the matrix above.
  • Attachments β€” the programme's own papers: the annual plan as approved, the scope document, the correspondence that set it up.

Active and passive​

A programme is created active. Standing one down is a row action on the list, not a field on the form.

A passive programme stops being offered for new audits β€” it disappears from the planning picker and from the unplanned-audit screen. The audits already under it are untouched: they stay readable, and the ones still in flight can still be finished. Standing a programme down ends new work, it does not cancel work in progress.

  • The audit β€” what gets planned in a programme
  • Audit types β€” the classification every audit carries