Management review
Overview
Section titled “Overview”ISO/IEC 42001 clause 9.3 asks top management to review the AI management system at planned intervals. The review considers the status of actions from previous reviews; changes in external and internal issues; changes in the needs and expectations of interested parties; the system’s performance (nonconformities and corrective actions, monitoring and measurement results, audit results); and opportunities for improvement. Its outputs are decisions on improvement and on any changes to the system, kept as documented information.
Govern → Compliance program → Management review keeps that record for one environment:
- The review: a title, the period it covers (at most 366 days), the meeting date and who attended.
- The input pack: generated from Shield360’s own records for the period, read only, each part linking to where it comes from.
- The reviewers’ notes: changes in issues, changes in interested parties’ needs, and opportunities for improvement.
- Decisions and actions: each with an owner, a due date and a status; any can become a finding.
- Sign-off: who signed it off and when. A signed-off review is kept as it was, input pack included.
Prerequisites
Section titled “Prerequisites”- To read reviews, you need the View the compliance overview permission (
compliance.read). Owners, administrators, the Compliance officer, Analyst and Viewer roles, and Auditors have it. - To create, hold and sign off reviews, 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. - Control status trends need the daily control history.
Hold a review
Section titled “Hold a review”The tiles show how many reviews there are, when the next is due, and how many of their actions are open and overdue.
Enter a title, the period it covers and the meeting date. Choose the attendees from the organisation’s members, and type up to 20 external attendees’ names.
Open the review. The input pack is generated for its period when you open it. Use it as the agenda for the meeting.
Fill in what changed and the opportunities for improvement. Add each decision or action with its kind, owner and due date.
Record as held once the meeting has taken place. Sign off records who signed it off and when, and keeps the input pack as it stands.
| Status | Next step | What it needs |
|---|---|---|
| Draft | Record as held | The meeting date has come, and at least one attendee. Records who and when. |
| Held | Sign off | Records who signed it off and when, and keeps the input pack. |
| Signed off | None | Only its actions’ status can change, and an action can still raise a finding. |
A step out of order is refused. Until it is signed off, a review’s details, notes and actions can change.
The input pack
Section titled “The input pack”The pack is generated from the platform’s records for the review’s period. It holds counts, ids, dates and statuses only, never text a person typed, and each part links to its page:
| Section | What it shows | From |
|---|---|---|
| Actions from the previous review | The last review held before this one: its decisions and actions, their status now and which are overdue. | Management reviews |
| Control status over the period | Each framework’s share of control-days met, gap days and days not recorded, and the controls with most gap days. | Daily control history |
| Nonconformities and corrective actions | Findings raised, closed, open, overdue and accepted as risks over the period, and effectiveness reviews confirmed by the history, judged effective, or judged not effective. | Findings |
| Internal audit results | Audits planned and reported in the period, and their nonconformities and observations. | Internal audits |
| Risk register changes | Risks added, risks whose score went up or down, and risks treated. | Risk register and its risk.update audit-log records |
| AI inventory changes | Assets first seen and retired in the period; assets without an owner and lapsed decisions now. | AI inventory |
| Statement of Applicability changes | Controls whose applicability changed in the period, and attested reviews overdue now. | Statement of Applicability and its controls.soa.update audit-log records |
The control history is read for the days of the period that have ended and are still kept (three years). Risk and applicability changes come from the audit log, so they cover changes made through Shield360. If a source cannot be read, its section says so and the rest of the pack is still shown.
The pack kept at sign-off
Section titled “The pack kept at sign-off”Until a review is signed off, the pack is generated each time it is opened, so it reflects the records as they are. Signing off keeps the pack as it stands with the review, so the record does not change when the history, the audit log or other data ages out or is edited later. A signed-off review always shows the pack kept at sign-off.
Decisions and actions
Section titled “Decisions and actions”Each decision or action has a kind (improvement, change to the AI management system, resources, other), a description, an owner, a due date and a status: open, in progress, done or cancelled. An action past its due date that is not done or cancelled is overdue.
Raise finding turns an action into a finding with source Management review, its description as the title and its owner and due date (or 30 days ahead if the due date has passed). The finding links back to the review, and the action links to the finding. Each action raises one finding at most.
Review interval and reminders
Section titled “Review interval and reminders”Reviews fall due 12 months after the last review held, unless you change the interval under Review interval and audit frequency (1 to 36 months). Before any review is held, the interval counts from when the settings were first saved. The same panel sets the audit frequency.
Once a day, after the control history is recorded, Shield360 raises a management_review.overdue alert when the next review’s due date has passed, once per due date. Holding a review moves the due date on. The alert carries the due date and the interval, never any text. Send it to a channel with an event rule for management_review.overdue on Alerts → Rules.
Evidence package
Section titled “Evidence package”Every evidence package includes the reviews that met in its period:
| File | Contents |
|---|---|
management-reviews.json | Each review with its period, meeting, attendees, status, notes, sign-off, decisions and actions, and the input pack kept at sign-off. |
management-reviews.csv | The same, one row per decision or action. Text that starts with =, +, - or @ is defused for spreadsheets. |
report.html has a Management reviews section with each review’s meeting, period, status, attendees, actions and sign-off date.
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 review, including its input pack, and change nothing. Member names are shown only to people who may change reviews; others see user ids.
Each change is written to the audit log as management_reviews.<step> (management_reviews.create, management_reviews.update, management_reviews.hold, management_reviews.sign_off, management_reviews.add_action, management_reviews.update_action, management_reviews.remove_action, management_reviews.raise_finding) with the review id, the statuses before and after, the names of the fields set and the action and finding ids. Changes to the settings are management_system.settings.update. The title, notes, names and action text are left out, because they may name a person and the audit log outlives them.
Reviews and their actions are part of the organisation export. A person export includes every review and action whose text names the person, and erasing the person clears that text and drops their name from the external attendees, signed-off reviews included, and keeps the review. The input pack holds no free text.
| Method | Path | Parameters |
|---|---|---|
GET | /api/governance/management-reviews | The reviews and the settings. |
POST | /api/governance/management-reviews | JSON body: title, periodFrom, periodTo, meetingDate (yyyy-mm-dd), and optionally attendeeUserIds, externalAttendees. |
GET | /api/governance/management-reviews/<id> | The review, its actions, the step it can take next and its input pack. |
PATCH | /api/governance/management-reviews/<id> | JSON body: action and what it records: update (any detail, issuesChanges, interestedParties, improvementOpportunities), hold, sign_off, add_action (category, description, owner, dueDate), update_action (actionId, any of those, status), remove_action (actionId), raise_finding (actionId, optionally severity, dueDate). |
GET, PUT | /api/governance/management-system/settings | JSON body for PUT: reviewIntervalMonths, auditFrequencyMonths (whole months, 1 to 36). Not available to Auditors. |
Malformed JSON, an id that is not a review id, a period that runs backwards or is longer than 366 days, an attendee who is not a member, too many or too long external names, or a field of the wrong kind returns 400. A review or action in another environment returns 404. A step the review cannot take from its status, a change to a signed-off review other than an action’s status, a finding already raised, or a review someone else changed meanwhile returns 409.
curl -X PATCH -H "Cookie: <session>" -H "Content-Type: application/json" \ -d '{"action":"add_action","category":"resources","description":"Train a second internal auditor","owner":"CISO","dueDate":"2027-03-31"}' \ "https://<your-shield360>/api/governance/management-reviews/<id>"