Skip to main content

Remediation Plan Layer and Exposure Brief Sequencing

Executive Summary​

SecurityV0 currently has a gap between a ranked recommendation and Create Ticket.

We are showing prioritized remediation ideas, but we are not yet giving the operator an execution-grade remediation layer. Wiz does. That is the missing step.

The correct operator flow is:

  1. See the risk.
  2. Open the exposure brief.
  3. Understand what is happening.
  4. Choose the best remediation plan.
  5. Open remediation plan detail.
  6. Execute or hand off.
  7. Verify closure.

For the next iteration, Engineering should do two things only:

  1. Add a new Remediation Plan Detail layer reachable from every clickable recommendation.
  2. Make a surgical sequencing change to the existing Authority Exposure Brief so remediation appears earlier than governance-condition support material.

This is not the brief redesign. The full visual redesign of the exposure brief will happen in a separate iteration with separate mocks.

Product Decision​

The operating model is:

  • Overview is for prioritization.
  • Authority Exposure Brief is the case file.
  • Top Remediation Plan is the recommended first intervention.
  • Remediation Plan Detail is the execution workflow.
  • Action is the target-specific change.
  • Ticket is the handoff artifact.

Findings are not part of the primary path for this work. They remain an investigation and evidence surface.

Terminology Decision​

Use these terms deliberately:

  • Risk reducer is the internal ranking term.
  • Remediation plan is the user-facing term.
  • Action is the concrete change on a specific path, chain, object, endpoint, role, or policy edge.
  • Target object is the thing being changed.
  • Object type is the source-system type of that thing.

This distinction matters because one ranked recommendation at the brief level may affect several paths or chains, but it does not necessarily collapse the entire cluster with one universal fix.

Example:

  • Assign accountable owner and invalidate expanded scope can be one remediation plan.
  • That plan may contain several actions, each tied to a different service principal or authority path.

What Is Missing Today​

Today the product path is effectively:

  1. Detect risk.
  2. Rank reducers.
  3. Create ticket.

That skips the operator's actual decision step:

  • what exact object changes
  • why this fix is the highest-leverage move
  • what exact action should be taken
  • how to verify that the fix worked

The product therefore behaves like a prioritization surface, not yet a remediation workflow.

New Layer: Remediation Plan Detail​

Purpose​

The new layer exists between recommendation selection and ticket creation.

Its job is to convert a ranked remediation plan into an actionable, verifiable set of changes.

Entry Point​

Each row or card in Top Remediation Plans should behave as an entry into one Remediation Plan Detail.

Click behavior:

  • open Remediation Plan Detail
  • preserve brief context
  • support return to the same exposure brief state

Engineering may implement this as a dedicated page or routed overlay, but it must behave like a first-class detail layer with URL-addressable state. It must not be treated as a transient ticket modal.

Required Information Hierarchy​

The new layer should contain these sections in this order:

1. Plan Overview​

State the recommendation in plain language:

  • what exact remediation plan is proposed
  • what kind of risky pattern it addresses
  • why this is the highest-leverage first move

Example framing:

Restrict LLM endpoint access to the exposed destinations in this cluster. This is the highest-leverage first move because it removes the active exfiltration vector affecting the most dangerous exercised paths in this brief.

2. Required Actions​

Show the concrete actions required to implement the plan.

Each action should be target-specific and operator-usable.

This section answers: what are the actual changes I need to make?

3. Compact Verification​

Show a small footer-level verification section:

  • SecurityV0 will recalculate exposure after the change
  • optional manual re-check steps
  • residual risk note only if needed

This section answers: what should I check after the action is made?

4. Handoff​

Create Ticket belongs on each action card, not as one global CTA.

The ticket payload should be generated from the same structured remediation data shown on screen for that action.

Remediation Plan Detail: What The Operator Must See​

The page guidance above is the information hierarchy. Engineering and design also need a clearer answer to a more practical question:

what should actually be visible on this page?

The operator should be able to understand five things within seconds:

  1. what the recommended plan is
  2. why it exists
  3. how many concrete actions it requires
  4. what kinds of objects it applies to
  5. where to start

Above-The-Fold Anatomy​

The first screen of Remediation Plan Detail should include:

1. Plan Header​

Show:

  • remediation plan title
  • brief or cluster name
  • severity and priority treatment
  • short one-sentence operator summary

This should read more like a recommended intervention than a record detail page.

2. Narrative Summary​

Show 1-2 short paragraphs that explain:

  • what risky pattern this plan addresses
  • why these actions belong together
  • what the operator should expect to change

If there is one useful shared fact, it can appear inline here, for example:

  • 2 required actions across 2 Foundry agents

Do not create a side panel or KPI strip for product-model metadata that does not directly help the operator act.

Required Actions Section​

This is the core of the page.

Each action card or row should show:

  • target object
  • object type
  • project when applicable
  • destination endpoint when applicable
  • current access mechanism
  • system to change
  • exact control to edit
  • role or binding to change
  • responsible owner or team
  • recommended change
  • execution guidance
  • one-sentence why this matters
  • per-action Create Jira Ticket

If the remediation plan spans multiple targets, group actions by shared pattern:

  • by object type, service principal, or workload
  • by endpoint or destination
  • by provider or control type

Do not flatten ten similar actions into an undifferentiated list if grouping improves comprehension.

Execution Guidance Presentation​

Execution guidance should be part of each action card and more prominent than generic rationale.

For each action, show one of the following:

  • exact command block
  • exact policy diff or binding change
  • explicit console path with named object
  • explicit handoff instruction when the change must be executed outside SV0

Execution guidance is informational. SV0 should remain read-only with respect to source systems; the product may guide the change and create tickets or tasks, but it should not execute the remediation itself.

If a field is unknown, show Not yet determined. Do not hide missing specificity behind generic prose.

Verification Presentation​

Verification should be present, but visually light.

The correct emphasis is:

  • action first
  • recalculation by SecurityV0 second
  • manual re-check third

Do not spend a third of the page on validation. A compact footer block is sufficient.

When A Plan Has Only One Action​

If a remediation plan resolves to a single concrete action:

  • keep the same page structure
  • show one action card
  • do not collapse plan and action into one unnamed blob

The model should remain consistent whether the plan contains one action or many.

When A Plan Has Many Actions​

If a remediation plan resolves to many actions:

  • preserve the plan-level narrative at the top
  • show grouped action lists below
  • allow scanning by target and provider
  • do not force the operator to infer which actions belong to the same plan

This is the critical case for ownership remediation and similar multi-principal fixes.

What Not To Show Prominently​

Do not let the page become:

  • a raw evidence dump
  • a findings-style table
  • a generic object detail page
  • a ticket modal with extra text
  • a side-panel metadata summary of internal product model labels
  • a standalone remediation module with its own separate navigation model

Evidence can be linked or summarized, but the page should stay centered on remediation understanding and execution.

Design Intent​

Remediation Plan Detail should feel like a visual child of the new Overview page and Exposure Brief direction:

  • strong narrative compression
  • bold primary statement
  • clear first action
  • minimal supporting context
  • evidence after meaning
  • embedded in the existing app shell and brief flow, not presented as a separate remediation product area

The operator should feel they are still inside the same product story, not dropped into a different admin console pattern.

Data Contract Principles​

The same remediation payload should drive:

  • plan summary card in the brief
  • remediation plan detail layer
  • action list
  • ticket body
  • later verification state

Minimum fields:

  • plan title
  • plan rationale
  • target object
  • object type
  • project
  • destination endpoint
  • current access mechanism
  • system to change
  • exact control to edit
  • role or binding to change
  • responsible owner or team
  • actions
  • execution instructions
  • verification instructions
  • per-action ticket payload

Interim Change: Authority Exposure Brief Sequencing​

This iteration is intentionally surgical.

We are not redesigning the full brief yet. We are only changing the sequence and emphasis so the operator sees remediation earlier.

Required Section Order​

The brief should now read:

  1. Highest-Risk Path
  2. What Happened
  3. Am I Exposed?
  4. How Do I Fix It?
  5. Governance Condition
  6. View Access Paths

Rationale:

  • What Happened explains the case.
  • Am I Exposed? quantifies scope.
  • How Do I Fix It? answers the next operator question.
  • Governance Condition is supporting explanation, not the primary next step.

Interim Layout Guidance​

Make only the following layout changes now:

1. Move How Do I Fix It? above Governance Condition​

This is the most important structural change.

2. Rename and increase emphasis on Top Remediation Plans​

The first recommendation should read like the recommended move, not just the first row in a list.

At minimum, each reducer should show:

  • action title
  • short why-this-matters sentence
  • impacted scope
  • number of affected actions or targets when greater than one
  • concise supporting signals

3. Make reducers clickable​

The click target should open the new Remediation Plan Detail layer.

4. De-emphasize the boxed feel of Am I Exposed?​

Do not redesign the section yet, but reduce the visual impression that it is a detached dashboard tile block. It should feel like part of the brief narrative, not a separate analytics widget.

Explicit Non-Goals For This Iteration​

Do not do the following in this workstream:

  • full Authority Exposure Brief visual redesign
  • Findings workflow redesign
  • cross-cluster remediation rollup
  • automated remediation execution
  • broad navigation refactor
  • new executive reporting surfaces

Those belong to later iterations.

Engineering Instructions​

Engineering should implement in two work packages.

Work Package 1: New Remediation Plan Detail Layer​

Requirements:

  • reachable from each recommendation in the exposure brief
  • URL-addressable
  • supports back-navigation to the originating brief
  • shows explanation-led header, required actions, compact verification, and per-action ticket handoff
  • stays inside the existing app shell and brief navigation context
  • does not introduce a separate remediation-module nav model or a global ticket CTA
  • reuses one structured remediation payload

Work Package 2: Brief Sequencing Change​

Requirements:

  • reorder the sections so How Do I Fix It? appears before Governance Condition
  • rename the section to Top Remediation Plans
  • make Top Remediation Plans visually stronger
  • make reducers clickable
  • keep the rest of the brief structurally intact for now

Claude Code Instructions​

Claude Code should treat this as an information-architecture and workflow change, not a broad design exploration.

Implementation rules:

  1. Do not redesign the whole exposure brief in this iteration.
  2. Do not push users into findings as the primary next step.
  3. Treat Remediation Plan Detail as a new product layer, not a ticket modal.
  4. Reuse the same remediation payload across brief card, plan detail, actions, and ticket.
  5. Keep ticket creation per action, downstream of the action content.
  6. Preserve the exposure-brief context when opening and closing remediation plan detail.
  7. Do not add a side panel for plan metadata unless it contains information the operator immediately needs to act.
  8. Do not hardcode identity terminology; use target object and object type.

Mocking Guidance​

Separate mocks will be provided for the new remediation plan detail layer.

Those mocks should inherit the design pattern already established for the revised overview direction:

  • strong narrative compression
  • clear operating story
  • explicit first action
  • evidence below meaning, not above it

For the current exposure brief iteration, mock changes should stay narrow:

  • reorder sections
  • strengthen reducer emphasis
  • make recommendation rows/cards behave as navigation into the new layer

Acceptance Criteria​

This iteration is successful if an operator can:

  1. land in the exposure brief and understand the case
  2. identify the recommended first remediation plan quickly
  3. click into a dedicated remediation plan detail layer
  4. understand which actions are required
  5. see the exact control surface to change on each action
  6. generate a ticket for each required action from the same payload

Open Follow-On Questions​

These questions are intentionally deferred, not blockers for this iteration:

  • Should remediation plan detail open as a full page or a routed drawer?
  • When do we aggregate one remediation plan across multiple briefs or clusters?
  • When is confidence high enough to emit raw commands automatically?
  • How should verification state roll back into tracked actions and closure UX?