Security Exception Workflow

What does this workflow record for each security exception?

Each exception is created as a record with a reference number, a status, and a timeline of activity. The security team's risk assessment task saves Risk Level, Review Conditions, and Expiry Date to the record, and the final approval or rejection outcome is reflected in the record status. Table views and dashboards let staff see exceptions grouped by their current status.

Who is involved in reviewing and approving a security exception?

The requester submits the initial request through a public form and receives acknowledgement and outcome emails. The security team is assigned the risk assessment task, and depending on the assessed risk level, approval is then requested from either the CISO (High risk) or the Security Manager (Low or Medium risk). All of these participants are workspace members who are assigned tasks or approvals as the workflow progresses.

How is the approver decided for each exception?

After the security team completes its risk assessment and sets the Risk Level, the workflow routes the request automatically: High risk exceptions go to the CISO for approval, while Low or Medium risk exceptions go to the Security Manager. This routing step ensures the approval task is assigned to the appropriate person based on the recorded risk level.

What happens if the CISO or Security Manager rejects the exception?

If either approver rejects the request, the workflow sets the record status to Rejected and sends the requester an email letting them know the exception was not approved. This outcome, along with the earlier risk assessment details, remains visible in the record's timeline.

What information does the requester receive if the exception is approved?

Once the CISO or Security Manager approves the exception, the workflow sets the record status to Approved and emails the requester confirming approval, including the expiry date and review conditions that were recorded during the risk assessment step. This gives the requester clear visibility into how long the exception is valid and what conditions apply.

How do we change the steps or timings in this workflow?

A workflow can be adjusted by describing the desired change in plain English or by editing the steps directly in the workflow editor, such as changing the risk assessment due date or adjusting email wording. Earlier versions of the workflow are kept, so changes can be reviewed against the previous configuration.

Can the request form be customised to capture additional details?

Yes, the public request form fields, such as Exception Requested, Affected Policy or Control, Justification, and Compensating Controls, can be edited to capture the information a workspace needs. Since this is a live template rather than a development project, changes to the form take effect for the workspace without a separate build or installation step.

Does the requester need an account to submit or track a security exception?

No account is required; the requester submits the initial request through a public form and receives updates, such as the acknowledgement, approval, or rejection emails, directly to their inbox. Any related forms sent to them, such as follow-up requests, are also completed without needing to log in.

How is progress on an exception tracked while it is under review?

The record's status moves through stages such as Submitted, Risk Assessment, Approved, or Rejected as the workflow progresses, and each change is logged in the record's timeline. Table views and dashboards allow staff to see how many exceptions are at each stage across the workspace.