Workflow lifecycle¶

RiskVault's default workflow branches according to assessment and treatment decisions. Administrators can change states, transitions, required fields, and permissions, so your organization's exact path can differ.

The journey from draft to closure¶

Intake — the creator prepares a draft with the basics: what the risk is, where it came from, and a first guess at how serious it is. Only the creator can see a draft.
Submission — the creator submits the draft. With automatic reviewer assignment, it goes straight to a reviewer and becomes Under Review. Otherwise it waits as Submitted until someone who can assign reviewers picks one.
Review — an analyst scores likelihood and impact, then validates the risk, returns it for more information, or rejects it. The risk owner is usually named at this stage.
Decision — a validated risk moves toward treatment or formal acceptance within tolerance.
Treatment — the plan is prepared, approved, performed, and completed.
Effectiveness and residual risk — the team checks whether treatment worked and scores the remaining exposure.
Monitoring — the risk is observed and reassessed when needed.
Closure — the outcome is documented, then the record may be archived. A closed risk can be reopened by someone with permission.

Image needed: Simple horizontal workflow diagram showing Intake, Review, Decision, Treatment, Residual Risk, Monitoring, and Closure, including the accept-within-tolerance branch.

RiskVault offers only the actions that make sense for the risk's current step and your role. When a button is greyed out, select it to open a checklist of exactly what's still needed. Each item links to its field, and the checklist updates once the missing information is saved.

Who does what¶

Submitter — creates and submits the risk, and answers the reviewer if they ask for more information.
Risk owner — named after submission, usually by the reviewer. Accountable for the risk and does the treatment work: writes the plan, sends it for approval, and carries it out.
Action owner — helps carry out the treatment: starting it, pausing and resuming it, and marking it complete.
Reviewer or analyst — assesses submitted risks and validates, returns, or rejects them.
Treatment approver — approves the plan before work begins. If the plan needs changes, the approver says so in a comment on the risk.
Tolerance approver — the governance decision-maker who authorizes accepting a risk rather than treating it.

One person can hold more than one responsibility if the organization's policies allow it.

RiskVault doesn't limit a step to the people named on the risk. Anyone whose role includes the permission for that step, and who can see the risk, can take it. If an action you expect is missing, the risk usually hasn't reached that step or you don't have that permission.

Who can be a risk owner¶

A risk doesn't need an owner to be created or submitted. The owner is chosen after submission, normally by the reviewer, and can't be set on a draft, because only the draft's creator can open it.

The owner is the person the system hands the treatment work to, so they need permission to do that work already. Naming someone as owner doesn't grant those permissions; it only puts the work in their queue.

Naming an owner does give them full access to that risk: they can read, edit, and delete it, moderate its comments, and manage who else can see it, even if it's sensitive or restricted to another department. That access lasts only while they are the owner. Replace them and it ends, unless someone also gave them a grant on the Permissions panel.

For both reasons, RiskVault checks the person before you save. If they aren't set up yet, a message names them, says what they can't do, and explains the fix. The check applies wherever you set an owner: editing a submitted risk, using the pencil on the Details page, or assigning in bulk from the register (drafts in a bulk selection are reported as not assignable).

If you can manage users, the message includes a button that assigns the person the Risk Owner Policy immediately. That is a permanent change to their account and applies to every risk.
If you can't manage users, the message tells you an administrator must make them eligible first. Pass the name along or choose someone else for now.

The other people fields are checked the same way, each against what that slot needs:

Slot	Needs
Reviewer	Review and disposition abilities
Action owner	Treatment-execution abilities
Treatment approver	The treatment-plan approval ability
Tolerance approver	The tolerance decision ability

The message always names the specific abilities the person is missing.

RiskVault also won't let you name an account that can't act at all: one that is deactivated, locked out, or the system's automation account. This check applies to the person being assigned, not the person being replaced, so you can always replace someone who has since been deactivated.

Risk imports, survey conversions, and risks created by connected systems are the only ways to name an owner at creation. Because nobody is present to answer a prompt, an ineligible owner is left blank and the process tells you it did so. See Import risks and Convert responses into risks.

If you submit a risk¶

After you submit, you don't need to do anything right away. You hear back only if the reviewer needs more information. In that case the risk returns to you as Requires More Info and you get a notification.

Read the reviewer's question.
Answer it in a comment, or in the fields themselves if you have edit access.
Resubmit. The risk goes straight back to the same reviewer.

Otherwise the reviewer validates the risk and it continues on its own. Follow its progress from the Risk Register, or use Watch to get updates.

Some organizations don't let people validate, reject, or request more information on a risk they created themselves. If you also hold reviewer permissions and those actions are missing on your own risk, a different reviewer must make that call. The setting is off by default.

Review an assigned risk¶

Open the item from My Work Items > To action.
Read the intake information and supporting files.
Enter likelihood and impact scores. They are required before you can validate.
Add required assessment notes.
Choose the appropriate decision:

Decision	Result
Request More Info	Returns the risk to the person who submitted it. Once resubmitted, it comes back to the same reviewer.
Reject	Stops processing and retains the reason. The risk can later be cloned into a new draft.
Validate	Confirms it is a real risk. Next, someone decides whether it needs treatment.
Mark as requiring treatment	The risk waits for someone to start planning treatment.
Mark as within tolerance	The risk waits for a governance approver to formally accept it.
Approve treatment plan	Clears the team to start the treatment work.
Complete treatment	The risk waits for an effectiveness review, then residual-risk scoring.
Close	Records the resolution and ends active work on the risk.

If you already know you need more information, use Request info directly from the row in My Work Items. Authorized reviewers can also reject from the row. Both ask for the same information and create the same audit history as the full risk page.

Common phases and states¶

Intake and review¶

Draft, Submitted, Under Review, and Requires More Info. Common actions include Submit, Assign Reviewer, Request More Info, Resubmit, and Reject.

Assessment and validation¶

Validated, Requires Treatment, Business Assessment: Within Tolerance, and Governance Approved. The risk branches toward treatment or, after tolerance approval, toward monitoring.

Treatment¶

Treatment Planning, Treatment Approved, Treatment in Progress, Treatment Completed, and On Hold. Actions can prepare, submit, approve, start, pause, resume, and complete the plan.

Sending a plan for approval doesn't lock it; the plan can still be worked on until it's approved. There's no separate “send back” step, so an approver who wants changes asks for them in a comment.

Effectiveness and residual risk¶

Effectiveness Review documents results. Residual Risk Assessment scores what remains. Insufficient treatment can send the risk back for more work; otherwise it can move to monitoring or be closed straight away.

Monitoring¶

Monitoring and Reassessment Scheduled support ongoing review. From monitoring, a risk can be scheduled for reassessment, sent back for more treatment, reopened for review, or closed.

Closure¶

Closed, Archived, and Rejected preserve terminal records. Closed and archived risks are read-only for ordinary editing, and reopening is a controlled action requiring permission and a reason.

A rejected risk can't be reopened. If it should be looked at again, use Clone Risk on the Details page or the Rejection Details tab to start a new draft from it.

Automated updates¶

Not every change is made by a person. A connected system — a monitoring tool, a ticketing system, or another internal application — can trigger the same automatic actions a workflow rule can, such as adding a comment or updating certain fields like the description or the likelihood and impact scores. When a score changes, the rating is recalculated.

Connected systems follow the same step rules people do. A field that is locked at the risk's current step is left alone, so nothing changes on a closed risk. A connected system can't move an existing risk to a different step. The one exception is a brand-new risk created by a connected system, which an administrator can set to be submitted for review immediately.

When a connected system changes a field, the risk's version history keeps a copy of how the risk looked before, and the audit log records each changed value with the rule and connection responsible. If a value looks unfamiliar, the history shows whether it came from a connected system rather than a colleague.

Workflow permissions¶

Each workflow action requires a claim. Closely related actions share one claim, so a role can't end up able to start something it can't finish, or give only one answer to a decision. Where a second person is meant to check the first person's work, the two steps keep separate claims.

Claim	Covers
`Risk.Submit`	Create drafts, submit, and resubmit risks
`Risk.AssignAnalyst`	Assign or change the reviewer
`Risk.Review`	Validate, reject, request more information, mark as requiring treatment
`Risk.MarkWithinTolerance`	Propose that a risk is within tolerance
`Risk.DecideTolerance`	Approve or decline a within-tolerance proposal
`Risk.PlanTreatment`	Plan treatment and submit the plan for approval
`Risk.ApproveTreatmentPlan`	Approve a treatment plan
`Risk.ExecuteTreatment`	Start and complete treatment
`Risk.HoldTreatment`	Put treatment on hold and resume it
`Risk.AssessOutcome`	Review effectiveness, assess residual risk, move to monitoring, schedule and complete reassessments
`Risk.Reopen`	Reopen a risk from monitoring or closure, or send it back for more treatment
`Risk.Close`	Close a risk
`Risk.Archive`	Archive a closed risk

Why an action is missing or blocked¶

Every transition checks the current state, your claim, your access to the risk, and required data. Seeing a risk does not imply permission to perform every action.

If an action fails, read its prerequisite message, complete and save the named fields, then retry. If RiskVault says the risk changed since you loaded it, someone else acted first: reload the risk, confirm it is still in the state you expect, and try again.