top of page

OneTrust

Governance, risk, and compliance platform

Every organization handled exceptions differently. Here's how I built one system that worked for all of them.

EXCEPTION MANAGEMENT

CONTEXT

OneTrust's users manage governance, risk, and compliance. Exceptions come up constantly: a policy deviation, a risk that needs a workaround, or a control that can't be fully met.

 

Before this project, exception management only existed for policy. Risk, issues, and controls had nothing, with no shared structure and no way to see everything in one place.

 

We talked to multiple internal teams and found each of them needed exception management. Each organization, and even the teams within it, handled exceptions differently. Everyone wanted one place to track all of them.

The brief was to build exception management for risk, issues, and controls. The harder part was that each domain works differently, and every organization has its own process on top of that. I couldn't just copy what existed for policy; it had to flex without falling apart.

THE PROBLEM

I interviewed six users across internal and external teams and tested three workflows: the risk exception request flow, the risk exception approval flow, and a new exceptions registry page.

 

Key findings:

  • Approval is highly contextual. It depends on business hierarchy and risk severity.

  • Users were confused about why risk review and exception review lived together. They felt like different things.

  • Users wanted exception information upfront on the details page, not buried in a relationship tab.

WHAT THE RESEARCH SHOWED

I separated exception review from risk review into two different flows. Two different jobs, two different places.

 

Exception details now sit upfront on the risk details page, visible without digging, but kept secondary so the page doesn't get overwhelming.

 

For intake, I borrowed existing form functionality from elsewhere in the platform so each organization could configure its own flow instead of being forced into one shared process.

 

And I built a single exception registry covering policy, risk, issues, and controls, so there's one place to see, manage, and track everything.

DESIGN DECISIONS

2.3.png

Exception details upfront: Key information on the risk details page, visible without clicking around.

2.4.png

Exception review separated from risk review: Exception request as its own flow, not buried inside risk review.

3.1 - Exception register.png

The exception registry: Every exception across policy, risk, issues, and controls. One place.

ExceptionManagement_OT.png

Configurable intake forms: Each organization sets up their own flow. The system doesn't force one.

  • Exception review separated from risk review

  • One registry across policy, risk, issues, and controls

  • Research validated every major decision before handoff
     

We handed this off to other teams to build. Research validated every major decision before it shipped. It shipped further down the roadmap after I'd moved teams, so I don't have adoption numbers.

OUTCOME

I'd push to stay through launch next time. Right now I know how the system was built. I want to know what the research got right and what it missed.

WHAT I'D DO DIFFERENTLY

bottom of page