Security Exception Workflow

How is this workflow audited?

Every step—from exception creation through risk assessment, approval routing, and final disposition—is logged with timestamps, actor identity, and status changes within assess.one. This creates a complete, exportable audit trail suitable for internal compliance reviews, external audits, or regulatory examinations. Rejection reasons and approval conditions are permanently recorded alongside the exception record.

Who has access to exception requests and approvals?

Access is governed by role-based permissions configured directly within assess.one, typically limiting risk assessment and approval actions to designated security team members and escalated approvers. Requesters can view the status and outcome of their own submissions without visibility into internal deliberations. Administrators can adjust these permission structures at any time as organisational roles evolve.

How does this integrate with our existing security tools and notification systems?

Notifications to requesters on approval or rejection are configured within assess.one and can be connected to email or Slack without any external development work. Integration setup is handled entirely inside the platform's configuration screens, allowing security teams to route alerts to existing communication channels immediately upon publishing the workflow.

Can the risk-based routing logic be customised?

Yes. The criteria that determine whether a request follows the Standard Security Approval or Escalated Security Approval path are fully configurable within assess.one's step logic. Organisations can adjust thresholds, add intermediate approval tiers, or introduce additional risk factors without any code changes.

What happens at the risk assessment decision point?

During Security Risk Assessment, the security team evaluates the request and records findings in the Record Risk Assessment step, which then determines routing via Route Approval by Risk Level. Lower-severity requests proceed to Standard Security Approval, while higher-severity or high-impact requests are automatically escalated to Escalated Security Approval for senior sign-off.

What is recorded when an exception is approved?

Upon approval, the workflow captures the expiry date and any review conditions before persisting the approved exception record and notifying the requester. This ensures every active exception has a defined lifespan and accountability owner, preventing indefinite or unmonitored deviations from security policy.

What happens if a request is rejected?

On rejection, the approver's reasoning is captured in the Capture Rejection Reason step, persisted to the record, and communicated directly to the requester via Notify Requester of Rejection. This ensures requesters receive clear, documented feedback and that the rationale remains available for future reference or appeal.

How long does it take to implement this workflow?

The template is ready to use immediately—publishing takes minutes, not weeks. Once published, your security and requesting teams can begin submitting and processing exception requests live, with roles, notifications, and approval logic already configured and adjustable as needed.

Who needs access to this workflow within our organisation?

Typically, requesters across business units, the security team responsible for risk assessment, and designated escalation approvers for higher-severity exceptions all require access. Access levels are assigned within assess.one and can be scoped tightly to reflect segregation-of-duties requirements common in security governance frameworks.

Can we adjust the review conditions or expiry requirements later?

Yes, the fields and logic governing expiry dates and review conditions are configurable directly within assess.one, allowing compliance or security leadership to tighten or adjust requirements as policy evolves. Changes take effect immediately upon republishing, with no disruption to exceptions already in progress.