By team
The policy is written down. The exceptions aren't.
Every control has a path around it, and that path is where the risk sits. stepbase makes the exception the documented part: a justification you can't skip, approvals at the level the request deserves, and an expiry date on the record.
Exceptions are the risky path, and they run on email
Someone needs admin rights for a migration, or a vendor onboarded before the security review finishes. It goes out as an email to a manager, gets a "fine by me", and the control is quietly off. Nobody wrote down why. Nobody named the compensating control. Nobody said when it ends. A year later an auditor asks how many exceptions are currently open, and nobody can produce the list, because the record was a thread in three inboxes.
Today
- Exceptions are requested by email, so there's no list of them
- "Business justification" is one line in a message, if it's there at all
- Whoever replies first is treated as the approver, regardless of the impact
- Compliance finds out about the deviation after it's already in place
- Nothing has an end date, so a two-week override becomes permanent
- There is no list of open exceptions, so nobody knows how many controls are currently off
On stepbase
- Every exception is filed on one form, so the open list is always current
- Policy reference, deviation, justification, risk, and compensating controls are required fields
- The request escalates by impact: manager, then compliance, then senior sign-off
- Compliance clears it with conditions, or rejects it on regulatory or precedent grounds
- A requested expiry date is captured on the record, not left implied
- Every approver's reasoning is timestamped against their name on the audit trail
How it works
- 1
Make the justification mandatory
The intake form asks for the policy being excepted, the specific deviation, the business case, the risk, the compensating controls, and an expiry date. Required fields mean an incomplete request never reaches an approver.
- 2
Escalate by impact, not by inbox
Condition blocks read what was submitted and pick the path. A low-risk one-off can end at the manager; anything precedent-setting or high-impact carries on to compliance and senior sign-off.
- 3
Put the right approver on each level
Route the manager step to the requester's manager, compliance to the compliance team's queue, and final sign-off to an admin role. Any of the three review steps can reject, and a rejection ends the request on a recorded outcome.
- 4
Require a comment on the decision
Approvers leave their reasoning with their decision, so the record shows not just that an exception was granted but on what grounds and with which conditions attached.
- 5
Keep the trail for the auditor
Each exception carries its own history: the justification submitted, every approver's decision and reasoning, and the expiry date that was agreed. Nothing to switch on, nothing to reconstruct.
Start from a template
Every template is fully editable: change the stages, forms, and routing to match how you work.
FAQ