Findings and remediation
A finding is a control that fell short, written down so somebody can fix it. Findings live under Compliance → Observations and carry their own lifecycle, independent of the engagement that raised them.
Who is who
| Role | Meaning |
|---|---|
| Owner | Accountable for the finding being closed. |
| Implementor | Doing the remediation work. |
| Verifier | Checks the work and closes it. Never the same person as the implementor. |
Everyone named must be a member of your organisation — the platform will not accept an outside user, because assignment sends them the finding's details.
The lifecycle
| Status | Meaning |
|---|---|
| Open | Raised, not yet being worked. |
| In remediation | Somebody is fixing it. |
| Remediated | The implementor says it is fixed. A claim, not a conclusion. |
| Verified closed | An independent person checked it. This is the only real close. |
| Accepted | The organisation has decided to carry this risk, for a stated period. |
| Overdue | The due date passed while the finding was still open or in remediation. |
Overdue is set by the platform each night, never by hand.
"Remediated" is the implementor's word for it. "Verified closed" is somebody else's. The person who claimed the remediation — and the assigned implementor — are both barred from verifying it, so no finding closes on one pair of hands.
Due dates and extensions
A finding gets a due date from its severity when it is raised. After that, the date is governed: it cannot be edited directly.
To move it, request an extension with a reason. A manager who is not the implementor decides. The original date is kept, so on-time closure is always measured against what was first committed to — an extension cannot make a late close look punctual.
Extensions are capped. The panel shows how many of the allowance have been used; once the cap is reached the request button is replaced by a line saying so, and the remaining choices are to remediate or to accept the risk with a rationale and an expiry. A manager sets the cap — and the two escalation intervals — under Settings → Remediation.
Follow-ups and escalation
If a finding goes quiet, send a follow-up round to the implementor. Rounds are numbered and tracked. An overdue finding that stays untouched is escalated to its owner automatically, and every overdue item appears in the daily digest. If it stays overdue for a further two weeks it is escalated a second time, to the organisation's managers. Both escalations are recorded on the finding and reset when it is reopened or given more time.
Root cause and repeat findings
Alongside the free-text root cause, give each finding a root-cause category — people, process, technology, policy, environment, third party or other. The category is what the analytics count: the free text explains, the category aggregates.
A finding that is carried into a new engagement period without being resolved wears a Repeat ×N badge, where N is the number of earlier periods it has survived.
What happens to the original depends on the state of the engagement it came from. Carrying forward from a completed period — the normal case — marks the original superseded: frozen, pointing at the live successor, hidden from the list unless you ask for it, and closed to every kind of edit. Carrying from an engagement that is still live copies the finding instead and leaves the original open, because closing it would quietly remove it from its own engagement's completion gate. A cancelled engagement cannot be rolled forward at all.
Working the list
The Observations list is built for triage. Each row shows the control, the engagement, the owner, how long the finding has been open, and how many days until — or past — its due date. Filter by severity, status, root-cause category or repeat findings only; sort by newest, due soonest, severity or longest open. Tick rows to assign an owner or set a category in one step; rows on a closed engagement or already superseded are skipped and reported, never silently changed.
Accepting a risk
Sometimes the answer is to carry the risk rather than fix it. Accepting a finding needs three things:
- A manager who is not on the doing side. Analysts cannot accept risk on the organisation's behalf, and neither can the finding's implementor, its owner or whoever claimed the remediation, whatever their role — the same independence rule as verify-close and extension decisions.
- A written rationale. Why is carrying this acceptable? At least ten characters — this is what a regulator reads.
- An expiry date, between seven days and two years out. Anything shorter is a deferral, not an acceptance, and would only serve to slip a finding past an engagement's completion gate.
Choose Accepted from the finding's status menu and the platform asks for both in a dialog. Once accepted, the rationale, who accepted it, when, and the expiry sit in a panel at the top of the finding.
At expiry the platform reopens the finding automatically, so an accepted risk comes back for a fresh decision instead of quietly becoming permanent. The panel stays, marked as lapsed, so the reopen is explained. Ending an acceptance early by hand is the same decision in reverse and needs a manager too; an analyst cannot undo it from the status menu.
Remediation evidence
Attach proof of the fix to the finding: upload a file, or record a reference to a document held elsewhere. Uploaded files get a platform-computed checksum; references are recorded as references. Once a finding is verified closed, its evidence set is frozen.
Escalating to the risk register
A finding that reflects something bigger than one control can be proposed to the risk register. The risk team accepts, rejects, or asks for more — the finding and the risk stay linked either way.
Your own queue
My Findings collects everything assigned to you: findings you own, findings you are implementing, and any evidence requests waiting on you.