Remediation
Turn governed Findings into accountable work without losing the context.
A Finding that nobody owns is a Finding that survives to the next audit. OTReady carries it through an explicit treatment decision into tracked work, keeps the architecture it is about attached to it, and closes it only when the work has actually been reviewed.
- One canonical board: framework and source are filters, not separate products
- A task keeps its Findings, its affected architecture and its evidence
- Review happens before approval, and closure has a rule
Lifecycle
Every step is somebody's decision.
- Governed Finding
- Treatment decision
- Remediate
- Remediation task
- Work
- Awaiting review
- Approved
- Finding closure
No assessment source creates a remediation task directly, and no operational alert does either. Work exists because a treatment decision said it should.
Awaiting review and approved are two different claims.
The distinction is the whole point of having a review step: one is the implementer speaking, the other is the reviewer.
Approved means the remediation work was reviewed and accepted. It is not a statement that a control, a framework, an asset or a project is compliant.
Awaiting review
Whoever did the work has offered it for review. It is a statement by the implementer, and it changes nothing about the Finding until a reviewer acts on it.
Approved
The implementation has been verified and accepted by a reviewer. This is the state that can contribute to closing the Finding it belongs to.
The board
One board, with filters, not a board per framework.
A task belongs to exactly one framework and never counts in another, but that is isolation within one canonical board rather than a reason to run several. Framework and source are views of the same work.
The board carries posture, counts by state, severity breakdown, and the gaps that have not been planned into work, alongside the columns themselves.
Task context
What a task carries with it.
The point of keeping context on the task is that whoever picks it up should not have to reconstruct why it exists.
- Linked Findings
- Which governed Findings this work answers. One task may address several, and one Finding may need several tasks.
- Affected architecture
- The Site, Zone, Subzone, Conduit, Channel or Asset the work concerns: the object itself, not a free-text note.
- Source and framework
- Where the underlying Finding came from, and which framework the task belongs to.
- Treatment
- The decision that created the work in the first place.
- Owner and deadline
- An assignee, a due date, and a visible overdue state.
- Activity and evidence
- An append-only message history, and the evidence offered for verification, so an approval cannot quietly change afterwards.
Closure is a rule, not a button.
A Finding becomes remediated when the linked remediation work satisfies the closure rule; it cannot simply be asserted. One Finding may relate to several tasks and one task may answer several Findings, so closure is evaluated across the links rather than inferred from whichever task was finished last.
There is no native ticketing integration today.
Work is tracked on OTReady's own board. A generic API path exists for connecting other systems, and it is described as exactly that. There is no Jira integration, no ServiceNow integration and no native connector to any ticketing product: naming one here would be describing something that does not exist.
Related capabilities
Findings & Evidence
Where the work comes from, and the evidence that verifies it.
Governance
Who may approve, and what the audit history records.
Reports
How remediation progress reaches an issued record.
See work that keeps its context.
Follow one Finding from a treatment decision to a reviewed, approved task on a real board.