Designing for Post-Audit Retention @ Secureframe

Timeline: Multi-phase rollout, shipped incrementally during live audits

The Team: 1 PM, 1 Designer (me), 1 Engineer, Compliance stakeholders

My Role: Led design for the Audit Portal. My PM defined scope and business framing; I owned design decisions—interaction model, information architecture, and UX flows.

When Success Became the Churn Risk

Secureframe's churn risk had shifted. Customers weren't leaving because they failed to get compliant—they were leaving after they succeeded.

Internal analysis revealed that ~40% of churn occurred after an audit report was issued. The pattern: once audit work moved into auditor portals, spreadsheets, and email, Secureframe became less central to day-to-day workflows. Customers started questioning whether they still needed the platform.

The goal: keep audit collaboration inside Secureframe so customers stay engaged through—and after—their audits.

The Inherited State

An earlier version of the Audit Portal existed, but it was built for internal visibility—helping Secureframe track which customers were in audit. It wasn't solving the retention problem because there was no way for auditors and customers to actually collaborate inside the platform.

Reframing the Approach

When my PM and I picked up the project, we shifted the focus from "track audits" to "keep audit collaboration inside Secureframe."

The question became: what would make auditors actually want to work here instead of their own portals?

Early on I proposed three constraints that I wanted the team to align on before we went into design. Getting PM and eng buy-in on those upfront meant fewer debates later about tradeoffs.

Give auditors clarity: A scoped view of what they need: test, evidence, context

Enable back-and-forth: Without forcing customers into external tools

Ship incrementally: Simple enough to release during live audits

Key design decisions #1 — Restructuring audit creation

The original "Add an audit" flow put all fields in a single form—framework, dates, audit firm. But these are distinct concepts that needed to be sequenced, not flattened.

❗️BEFORE: All fields in one flat form

✅ AFTER: Guided 3-step flow separating framework, evidence scope, and auditor access

Separating these concepts reduced cognitive load and prevented configuration errors—especially important since audits can't be easily restarted once evidence is scoped wrong.

Key design decision #2 — The "responses" model

The previous system showed test health statuses (passing/failing). But auditors don't care about health—they care about whether evidence is ready for review.

I introduced a "Response" model: tests are marked as Submitted, Action Required, or Accepted. This reframed the UI around audit workflow, not compliance state.

A. Response counts replace health status as the primary progress indicator

B. Tests show audit readiness (Submitted, Action required, Accepted)

C. Dropdown lets users update response status directly

Key design decision #3 — Collaboration without leaving the platform

To keep communication inside the platform, each test has two comment threads: Auditor comments (shared with the auditor) and Internal comments (visible only to the customer's team).

This lets customers coordinate internally before responding—without switching to Slack or email. Auditors see a single "Comments" tab; they don't need to know an internal thread exists.

Auditors see a single "Comments" tab—they don't need to know an internal thread exists.

Admins see both Auditor comments (shared) and Internal comments (private). Auditors only see the shared thread.

Key design decisions #4 — Two users, one audit

The Audit Portal serves two users: company admins running the audit, and external auditors reviewing evidence. They collaborate on the same audit object, but with different permissions and information needs.

Admins can manage the audit, see internal health statuses, and mark tests as ready for review.

Auditors see a scoped-down view focused only on what they need to evaluate—and can mark tests as Accepted or Action Required.

1. Can edit and delete audits

B. Health status visible

C. Marks tests as "Submitted" or "Not ready"

1. No edit controls

B. Health status hidden

C. Marks tests as "Accepted" or "Action Required"

The Shipped Product

Audit List View

The audits dashboard shows all active and upcoming audits at a glance. Progress bars and response counts let admins quickly assess where each audit stands without clicking in.

Test List View

The primary working surface during an audit. Tests are organized by response status—Not ready, Submitted, Action required, Accepted—so admins and auditors can focus on what needs attention.

Add Audit Wizard

The wizard separates what's being audited (observation window) from when auditors get access (audit dates)—two concepts the previous design conflated in a single form.

Framework Tab

For audits tied to compliance frameworks, this view organizes progress by clause structure. "X of Y tests accepted" roll-ups help auditors verify coverage without reviewing every test individually.

Test Detail Panel

Clicking a test opens the detail panel with evidence, mapped controls, and comments. Auditor comments are shared; internal comments stay private to the customer's team.