Findings and corrective actions

Overview

A finding is one nonconformity in one environment: a control that is not met, an attested review that is overdue, or something an internal audit, a management review or an external auditor found. Govern → Compliance program → Findings keeps each finding through the steps ISO/IEC 42001 clause 10.2 describes:

1. React to it: record how it was contained and corrected.
2. Find the cause: record the root cause.
3. Act: plan the corrective action, with an owner and a due date, and mark it done.
4. Review effectiveness: after a review period, check that the action worked.
5. Keep documented information: every step is kept with who took it and when, and goes into the evidence package.

Shield360 suggests findings from what it observes, but never raises one by itself. A person reads the suggestion and decides.

Caution

Findings are a record for you and your auditor. They are not a certification, an audit opinion or a statement of conformity with ISO/IEC 42001 or any other standard. Only an accredited certification body can certify an organisation.

Prerequisites

• To read findings, you need the View the compliance overview permission (compliance.read). Owners, administrators, the Compliance officer, Analyst and Viewer roles, and Auditors have it.
• To raise findings and move them through the workflow, you need the Manage findings and corrective actions permission (compliance.findings.manage). Owners, administrators and the Compliance officer role have it. Auditors never do.
• Suggestions from control gaps need the daily control history, which records each control’s status once a day.

Raise a finding

Open Govern → Compliance program → Findings

The list shows how many findings are open, overdue, awaiting their effectiveness review, accepted as risks and closed.

Select Raise a finding

Enter a short title and description, the source, the severity, the owner, and the date the corrective action is due.

Link the controls and, optionally, a risk

Enter the control ids of one framework, such as A.6.2.7, A.7.5, and choose an AI risk from the risk register if the finding is about one.

Keep the text short and factual. Do not paste prompts, telemetry, request contents, credentials or personal data into a finding: describe what was found and refer to the evidence. Shield360 never copies telemetry into a finding.

Sources

Source	When to use it
Control gap	A control’s latest day in the control history is a gap. Raised from a suggestion.
Attested review overdue	An applicable control’s Statement of Applicability review is overdue. Raised from a suggestion.
Internal audit	Your internal audit found it. Raised from a nonconformity on the audit, which it links back to.
Management review	Your management review decided on it. Raised from a review’s action, which it links back to.
External auditor	An external or certification auditor found it.
Raised by hand	Anything else.

Suggested findings

The Findings panel on Govern → Compliance program → Framework controls shows how many findings are open and overdue. To people who may raise findings, it also lists suggestions for the framework on screen:

• Control gap: the control’s latest recorded day in the daily history, within the last three days, is a gap. The suggestion says since when the run of gap days began.
• Attested review overdue: an applicable control of a framework with a Statement of Applicability has a review that is past due.

Select Raise finding next to a suggestion to open the form already filled in with the control, a title, a description built from the control id, its title and the ids of the checks behind the gap, and a due date 30 days ahead. You can change the text, severity, owner and due date before you raise it. The source and linked control stay as suggested.

A control is not suggested again while a finding that is not closed (including one accepted as a risk) covers it, and the server refuses to raise the same suggestion twice. Once a finding is closed, the control can be suggested again if it goes back to a gap.

The workflow

Status	Next step	What the step records
Open	Record containment	What was done to control and correct it.
Contained	Record root cause	The root cause.
Root cause recorded	Plan corrective action	What will remove the cause. The finding needs an owner first.
Action planned	Mark action done	When it was done, and the review period: 30 days by default, 7 to 365.
Action done	Verify effectiveness	From the control history, or a reviewer’s judgement with a reason.
Effectiveness verified	Close finding	When it was closed.
Open, contained, root cause recorded or action planned	Accept as risk	Why it is accepted, and who approved it.
Accepted as risk	Reopen	Nothing; it goes back to open.

A step out of order is refused. A finding can only close after its action was judged effective. A closed finding cannot be changed. While a finding is not closed, its title, description, severity, owner, due date and links can change.

Each finding shows a timeline of every step: what it was, the status before and after, the names of the fields it set, who took it (a user id) and when. The text itself is kept on the finding, not repeated in the timeline.

Effectiveness review

Marking the action done schedules the review. The review period runs from the day after the action was done to the end of the review period, in UTC days. The finding can then be verified in one of two ways:

• From the control history. Once the review date has passed, Verify from control history is available when every linked control was met on every day of the period. A day without a record in the history is not recorded and does not count as met, as everywhere else the history is read.
• By a reviewer’s judgement. A reviewer records whether the action was effective, with a reason of at least 10 characters. Use it for a finding with no linked controls, or when the history does not settle it. If the action was not effective, the finding goes back to Action planned with the reason kept, so the action can be planned again.

While the action awaits its review, the finding shows each linked control’s days met, with a gap and not recorded so far, and why the history cannot settle it yet.

Overdue findings

A finding is overdue when its due day has ended and its corrective action is not done (it is open, contained, root cause recorded or action planned). Overdue findings are counted on Govern → Compliance program → Framework controls and Govern → Compliance program → Findings, and Overdue only filters the list.

Once a day, after the control history is recorded, Shield360 raises a finding.overdue alert for each finding that became overdue. It is raised once per due date: moving the due date and letting it pass again raises it again. High and critical findings raise a critical alert; others a warning. The alert carries the severity, the linked control ids, the due date and the status, never the title or other text, because alerts go to chat and email. Send it to a channel with an event rule for finding.overdue on Alerts → Rules.

Evidence package

Every evidence package includes the findings for its period:

File	Contents
findings.json	Each finding raised before the end of the period and not closed before it began, with its status at the end of the period, what was recorded at each step and every step up to the end.
findings.csv	The same, one row per finding. Text that starts with =, +, - or @ is defused for spreadsheets.

report.html has a Findings and corrective actions section: how many were raised and closed during the period, how many were open, overdue and accepted as risks at its end, and a table of the findings.

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.

Each step is written to the audit log as findings.<step> (findings.create, findings.contain, findings.close, and so on) with the finding id, the statuses before and after, the names of the fields set, the severity, the due date and the linked controls. The title, description, owner, approver and recorded text are left out, because they may name a person and the audit log outlives them.

Findings and their steps are part of the organisation export. A person export includes every finding whose text names the person, and erasing the person clears that text and keeps the finding and its timeline.

API

Method	Path	Parameters
GET	/api/governance/findings	Optional status, severity, owner, control, framework and overdue=1. The findings, the counts over all of them and the owners.
POST	/api/governance/findings	JSON body: title, dueDate (yyyy-mm-dd), and optionally description, severity (low, medium, high, critical), owner, source, framework and controlIds, riskId, suggestionKey.
GET	/api/governance/findings/<id>	The finding, its steps, the next steps it can take and, while its action awaits review, what the control history says.
PATCH	/api/governance/findings/<id>	JSON body: action and what it records: contain (containment), record_root_cause (rootCause), plan_action (actionPlan), complete_action (reviewDays), verify_effectiveness (basis: history, or manual with effective and reason), close, accept (justification, approver), reopen; or update with any of the details.
GET	/api/governance/findings/suggestions	framework. The suggested findings for that framework. Not available to Auditors.

Malformed JSON, an id that is not a finding id, a control id the framework does not have, a due date in the past or more than three years away, or a field of the wrong kind returns 400. A finding in another environment returns 404. A step the finding cannot take from its status, a closed finding, a suggestion a finding already covers, or a finding someone else changed meanwhile returns 409.

curl -X PATCH -H "Cookie: <session>" -H "Content-Type: application/json" \
  -d '{"action":"verify_effectiveness","basis":"manual","effective":true,"reason":"Reviewed a month of approvals; no bypass."}' \
  "https://<your-shield360>/api/governance/findings/<id>"

Next steps

Controls

Control status, the Statement of Applicability and the daily history findings are suggested from.

Evidence package

A signed ZIP of this evidence, findings included, for an auditor.

Risk register

The AI risks a finding can be linked to.

Internal audit

Audits whose nonconformities raise findings.

Management review

Reviews that consider findings and can raise them from actions.