Internal audit
Overview
Section titled “Overview”ISO/IEC 42001 clause 9.2 asks an organisation to run internal audits at planned intervals: an audit programme with each audit’s scope and criteria, auditors who are objective and impartial, results reported to management, and nonconformities fed into corrective action, all kept as documented information.
Govern → Compliance program → Internal audits keeps that record for one environment:
- The programme: audits planned per year, when each control was last audited, and the controls not audited within your audit frequency.
- Each audit: its title, framework and controls in scope (or all of them), scope and criteria, planned date and lead auditor.
- Independence: a warning when the lead auditor owns a control or finding in scope, and the reason recorded to go ahead.
- Results: a conclusion on each control in scope, a summary of the results, and a finding raised from each nonconformity with one click.
Prerequisites
Section titled “Prerequisites”- To read audits, you need the View the compliance overview permission (
compliance.read). Owners, administrators, the Compliance officer, Analyst and Viewer roles, and Auditors have it. - To plan and record audits, you need the Manage internal audits and management reviews permission (
compliance.reviews.manage). Owners, administrators and the Compliance officer role have it. Auditors never do.
Plan an audit
Section titled “Plan an audit”The tiles show how many audits are planned, in progress, reported and overdue, and how many controls are due for audit.
Enter a title, the framework and the planned date. List the control ids in scope, such as A.6.2.7, A.7.5, or leave the list empty to audit every control of the framework.
The scope says what is audited (teams, systems, processes). The criteria say what it is audited against: the standard, your policies and procedures.
Choose a member of the organisation, or Someone external and type their name. You can plan an audit before choosing; it cannot start without one.
Keep the text short and factual. Do not paste prompts, telemetry, credentials or personal data into an audit.
Auditor independence
Section titled “Auditor independence”Clause 9.2.2 asks that auditors be objective and impartial. When an audit is planned, its lead auditor changed, or it is started, Shield360 checks whether the lead auditor owns anything in scope:
- a control in scope whose Statement of Applicability owner names them, or
- a finding that is not closed, about a control in scope, that they own.
Owners are free text, so the check matches the lead auditor’s name and email (or the name typed for an external auditor) as whole words, case-insensitive. When something matches, the change is refused with the list of conflicts, such as control:A.6.2.7 or finding:<id>. Choose someone else, or record why the lead auditor may audit this scope (at least 10 characters), for example because they are the only trained auditor and someone independent reviews the report. The conflicts and the reason are kept with the audit and shown on it.
Run and report the audit
Section titled “Run and report the audit”| Status | Next step | What it needs |
|---|---|---|
| Planned | Start the audit | A lead auditor, and a reason if they own something in scope. Records who started it and when. |
| In progress | Record conclusions | A conclusion on each control in scope, with a short note. |
| In progress | Report the results | A conclusion on every control in scope (“Not audited” is one) and the results written up. Records who reported it and when. |
| Reported | None | Nothing changes, except findings raised from its nonconformities. |
The plan (title, scope, criteria, date, controls, lead auditor) can change only while the audit is planned. A step out of order is refused.
Conclusions
Section titled “Conclusions”| Conclusion | Meaning |
|---|---|
| Conforms | The control meets the criteria. |
| Minor nonconformity | A requirement is not fully met, without a systemic failure. |
| Major nonconformity | A requirement is not met, or the failure is systemic. |
| Observation | Something to watch or improve; not a nonconformity. |
| Not audited | The control was in scope but was not audited. |
Raise a finding from a nonconformity
Section titled “Raise a finding from a nonconformity”Next to each minor or major nonconformity, Raise finding creates a finding with source Internal audit, linked to the control, with the conclusion’s note as its description. A major nonconformity starts at high severity and is due in 30 days; a minor one at medium and 60 days. You can change them on the finding. The finding links back to the audit, and the conclusion links to the finding. Each conclusion raises one finding at most.
The audit programme
Section titled “The audit programme”Below the list, the programme for the framework you choose shows:
- audits planned and reported per year (by planned date);
- for each control, when a reported audit last reached a conclusion on it and what it was (“Not audited” does not count);
- controls not audited within the audit frequency, highlighted.
The audit frequency is 12 months unless you change it under Govern → Compliance program → Management review → Review interval and audit frequency (1 to 36 months).
Overdue audits
Section titled “Overdue audits”An audit still planned after its planned day has ended is overdue. Once a day, after the control history is recorded, Shield360 raises an internal_audit.overdue alert for each audit that became overdue, once per planned date: moving the date and letting it pass again raises it again. The alert carries the framework, the planned date and the number of controls listed, never the title or other text. Send it to a channel with an event rule for internal_audit.overdue on Alerts → Rules.
Evidence package
Section titled “Evidence package”Every evidence package includes the audits planned or reported in its period:
| File | Contents |
|---|---|
internal-audits.json | Each audit with its scope, criteria, lead auditor, independence conflicts and reason, status, results, and every control in scope with its conclusion, note and finding. |
internal-audits.csv | The same, one row per control in scope. Text that starts with =, +, - or @ is defused for spreadsheets. |
report.html has an Internal audits section with each audit’s status and how many controls conformed, had minor or major nonconformities or observations.
Access and privacy
Section titled “Access and privacy”Every read and change is scoped to your current environment, taken from your session, never from the request. Changes need a signed-in person; an API key cannot make them. An Auditor can read the list and each audit, and change nothing.
Each change is written to the audit log as internal_audits.<step> (internal_audits.create, internal_audits.start, internal_audits.conclude, internal_audits.report, internal_audits.raise_finding) with the audit id, the statuses before and after, the names of the fields set, the framework, planned date, number of conflicts and whether a reason was recorded. The title, scope, criteria, notes, results, names and reason are left out, because they may name a person and the audit log outlives them.
Audits and their conclusions are part of the organisation export. A person export includes every audit and conclusion whose text names the person, and erasing the person clears that text and keeps the audit.
| Method | Path | Parameters |
|---|---|---|
GET | /api/governance/internal-audits | Optional framework for the programme (ISO/IEC 42001 by default). The audits, the programme and the settings. |
POST | /api/governance/internal-audits | JSON body: title, framework, plannedDate (yyyy-mm-dd), and optionally controlIds, scope, criteria, leadAuditorUserId or leadAuditorName, overrideReason. |
GET | /api/governance/internal-audits/<id> | The audit, every control in scope with its conclusion, and the step it can take next. |
PATCH | /api/governance/internal-audits/<id> | JSON body: action and what it records: update (any detail, overrideReason), start (overrideReason), conclude (conclusions: [{ controlId, conclusion, note }], summary), report (summary), raise_finding (controlId, optionally severity, dueDate, owner). |
Malformed JSON, an id that is not an audit id, an unknown framework or control, a date more than three years away, a lead auditor who is not a member, or a field of the wrong kind returns 400. An audit in another environment returns 404. A step the audit cannot take from its status, an unresolved independence conflict, a missing conclusion, a finding already raised, or an audit someone else changed meanwhile returns 409.
curl -X PATCH -H "Cookie: <session>" -H "Content-Type: application/json" \ -d '{"action":"conclude","conclusions":[{"controlId":"A.6.2.7","conclusion":"major_nc","note":"No approval records for June."}]}' \ "https://<your-shield360>/api/governance/internal-audits/<id>"