Skip to content
English
Customer portal
Contact us
  • There are no suggestions because the search field is empty.

09.07 Understanding SimpleRisk Workflows

Two distinct things in SimpleRisk are called "workflow" — the built-in per-entity status lifecycles (risks, audits, incidents) and the Workflows Extra (custom event-driven automation). Here's the difference and when to reach for each.

Why this matters

The word "workflow" gets used for two genuinely different things in SimpleRisk, and conflating them produces confused conversations. Knowing which is which is the prerequisite for any conversation about how a process gets implemented.

The two things:

  • Built-in entity workflows are the hardcoded status lifecycles attached to each major entity type. A risk moves through New → Mgmt Reviewed → Mitigation Planned → Closed; an audit moves through Not Started → In Progress → Complete → Pass/Fail; an incident moves through Identification → Containment → Eradication → Recovery → Closed. These are baked into SimpleRisk's data model and code; they're not customizable, they're not optional, they don't have a configuration surface. They're how SimpleRisk represents "what state is this entity in?" at the application level.
  • The Workflows Extra is an optional add-on that adds custom event-driven automation. Customers can define custom workflows (when X happens, send Y email or trigger Z action) with their own triggers, conditions, and actions. It's a programmable surface; it ships with sensible defaults but the customer authors what runs.

The two systems coexist. The built-in lifecycles handle the per-entity state machine; the Workflows Extra handles the cross-cutting "when something happens, also do this other thing" automation. Programs that need only standard SimpleRisk behavior get by on the built-in lifecycles alone; programs that need custom notifications, custom routing, custom escalations, or custom integrations install the Extra.

The other reason this matters: when you're trying to do something process-related and asking "is there a workflow for that?", the answer depends on which kind of workflow. The built-in lifecycles are baked in (there's no "create a new built-in workflow" path); SimpleRisk handles the state transitions for you, and customizing them requires source-code changes. The Workflows Extra is the customization surface; if you need custom event handling, that's where it lives.

How frameworks describe this

Most major frameworks talk about "workflows" in the broader process-management sense rather than tying the term to specific tooling. The relevant framework references:

  • NIST SP 800-53 PM-9 (Risk Management Strategy) and PM-10 (Authorization Process) describe the workflows for risk and system authorization without prescribing specific implementations. The workflows are processes the program runs, not specific software flows.
  • NIST CSF v2.0 under Govern function describes the cyclical risk management workflow at a strategic level — the same identify-assess-treat-monitor-report loop covered in The GRC Program Lifecycle.
  • ISO/IEC 27001 clause 8 (Operation) describes operational planning and control as ongoing process, with documented procedures for the security operations the ISMS supports.
  • NIST SP 800-61 four-phase IR lifecycle (Preparation, Detection & Analysis, Containment/Eradication/Recovery, Post-Incident Activity) is itself a workflow — and one that SimpleRisk's Incident Management Extra implements explicitly. See What is Incident Response?.

The framework view is "your program runs workflows; how you implement them is up to you." SimpleRisk's split between built-in lifecycles and custom Workflows Extra is one implementation; other GRC tools take different approaches (configurable workflows from the start, no custom workflows at all, etc.).

How SimpleRisk implements this

The built-in entity workflows

Each major entity in SimpleRisk has its own status lifecycle. The lifecycles are hardcoded; the state transitions happen in response to user actions or programmatic API calls.

Risk lifecycle:

  • New (status 1 in the underlying database) — risk submitted but not yet reviewed.
  • Mgmt Reviewed — first management review has been submitted (see Reviewing and Approving Risks).
  • Mitigation Planned — a mitigation has been recorded (see Mitigating a Risk).
  • Closed (with various closure reasons) — risk no longer active.
  • Reopened — was closed, now reactivated.

The transitions happen automatically based on user actions (submitting a review changes status to Mgmt Reviewed; saving a mitigation changes status to Mitigation Planned). There's no "skip a state" path; the lifecycle progresses linearly through the actions that drive each transition.

Audit / control test lifecycle:

  • States: Not Started → In Progress → Complete with final result Pass / Fail / Inconclusive.
  • The transitions happen as the audit's actions are performed (see Control Tests and Evidence Collection).

Incident lifecycle (with Incident Management Extra):

  • The Extra implements NIST 800-61's four phases as the incident's status: New (status 1) → Containment (2) → Eradication (3) → Recovery (4) → Closed (statuses 5–11 with various closure reasons). See The Incident Management Extra.

Document exception lifecycle:

  • Created → Unapproved → Approved (and back to Unapproved when updated, per the load-bearing rule documented in Exceptions Management).

Document lifecycle:

  • Status values typically include Draft → In Review → Approved → Retired, configurable per install.

These built-in workflows are part of SimpleRisk's behavior; you don't configure them, you operate against them. The user-facing surface for each is the entity's detail view, where the appropriate action button (Save Review, Save Mitigation, Approve Exception, etc.) drives the next state transition.

The Workflows Extra

The Workflows Extra lives at simplerisk/extras/workflows/ and is an admin-installed, admin-activated capability for custom workflow automation. The Extra's data model includes:

  • workflow_definitions — the workflows the customer has authored, with triggers, conditions, and actions.
  • workflow_email_templates — email templates the workflows use for notification actions, with placeholder substitution syntax ( style).

Two types of workflows live in the Extra:

  • System workflows (system_workflow=1) — seeded on Extra activation. The Extra ships with at least one default workflow (a "New Risk Submitted" workflow that fires when a risk is created and sends a notification email using the seeded template). System workflows can be edited but aren't deleted when the Extra is deactivated.
  • Custom workflows (system_workflow=0) — authored by the customer. These are deleted when the Extra is deactivated (the schema remains; the data is cleared).

What customers build with the Workflows Extra:

  • Custom notification routing — emails to specific people based on entity attributes (e.g., "if a risk's category is 'Privacy', also notify the privacy officer").
  • Custom field updates — automatically populate or modify fields based on triggering events.
  • Custom escalations — recurring notifications to managers when items remain in a particular state too long.
  • Integration triggers — fire calls to external systems via custom action handlers.

The Workflows Extra and the Notification Extra (covered in Notifications and Email Preferences) overlap: both can send emails on events. The distinction is configurability — the Notification Extra has a fixed set of events and routing rules with simple toggles; the Workflows Extra is open-ended and lets customers author whatever logic they need.

For installations running both Extras, the operational pattern is usually: the Notification Extra handles the standard notifications (the predictable per-event sends to standard roles), and the Workflows Extra handles the specific custom logic that doesn't fit the Notification Extra's templates.

Common pitfalls

A handful of patterns recur with workflow understanding.

  • Conflating "workflow" with "the Workflows Extra." The most common confusion. A user asking "how do I customize the risk workflow?" might mean "how do I customize the risk lifecycle states?" (answer: you can't, it's hardcoded) or "how do I add custom automation to the risk submission?" (answer: use the Workflows Extra). Clarify which kind of workflow before reaching for an answer.

  • Trying to skip built-in workflow states. The risk lifecycle goes through Mgmt Reviewed before Mitigation Planned. A user who wants to plan a mitigation on an unreviewed risk can't directly skip the review state. The workaround is either to do the review (recommended), or to configure the install in a way that bypasses the review requirement (admin setting that may exist depending on version), or to live with the state machine.

  • Building custom workflows for capabilities the Notification Extra already covers. A Workflows Extra workflow that "sends an email when a new risk is submitted" duplicates what the Notification Extra's NOTIFY_ON_NEW_RISK=true already does. Use the simpler tool when the simpler tool suffices; reserve the Workflows Extra for genuinely custom logic.

  • Authoring workflows without testing. A workflow that fires on every new-risk event and runs custom logic may produce unexpected results in production. Test workflows on test data first; deactivate them quickly if they misbehave; iterate.

  • Forgetting that the Workflows Extra deactivation deletes custom workflows. Deactivation is destructive for custom-authored workflows; the schema persists but the data is cleared. Back up workflow definitions before deactivating the Extra.

  • Not coordinating workflow customization with the Notification Extra's settings. Both Extras can send emails on events. A program with both running may produce two emails for the same event — one from the Notification Extra and one from the Workflows Extra workflow. Coordinate to avoid duplicates; either disable the Notification Extra event for cases the Workflows Extra workflow handles, or have the Workflows Extra workflow check whether the Notification Extra has already fired (which requires custom action logic).

  • Treating the built-in workflow states as configurable enums. The status enum on each entity (the integer values that map to "New", "Mgmt Reviewed", etc.) is hardcoded. Customizing the labels for the existing states is sometimes possible via admin configuration; adding new states or removing existing ones requires source-code changes and isn't supported.

  • Writing workflow templates with placeholder typos. The Workflows Extra's email templates use syntax. A typo'd placeholder (e.g., instead of ) results in literal placeholder text appearing in sent emails. Test templates by triggering test events and reading the resulting emails; check for unsubstituted placeholders.

Related