Skip to main content

SecurityV0 Design Principles

North Star: CISOs and systems integrators come to SecurityV0 to pull data straight into their executive or board presentations. — Sergey, 2026-03-16

These principles guide every product change. Before merging a PR that touches UI, findings, remediation, or reports, validate it against these.

The Principles​

1. Finish the Sentence​

Every finding, every remediation, every cluster summary must state the business conclusion — not just the technical fact.

Test: Read the output aloud. If a non-technical VP would ask "so what?", the sentence is unfinished.

UnfinishedFinished
"Gained foundry_ai_executor role, 0→1 since baseline""An unowned AI agent now has write access to your identity provider — if compromised, an attacker can provision accounts"
"Restrict LLM endpoint access""Restrict LLM endpoint access — this agent sends data to Azure OpenAI. Restricting may stop the AI Triage workflow. Verify with the platform team before acting."
"Orphaned ownership""The person who set this up (Maria Lopez) left the company. Nobody inherited it. It's still running."

Triage decision rule (Sergey #2): Every finding should guide the analyst to one of four actions: investigate now, ticket now, watch, or ignore. The UI should make this decision obvious — not just show the problem.

Source: Sergey feedback #1-6 — business impact framing, "so what?" gap, remediation must show impact of both problem and fix, triage tied to business impact.

2. Guide the Eye​

The UI should tell the user where to look first through color, size, and position — not through more text or more data.

Test: Show a screen to someone for 5 seconds. Can they point to the most important thing? If everything looks equally important, nothing is.

Rules:

  • The most critical item is visually largest and highest on the page
  • Use color to encode urgency (red = act now, amber = investigate, blue = informational)
  • Use shape and weight to create hierarchy (bold = primary, regular = supporting, muted = metadata)
  • A junior analyst should know where to click first without reading a guide

Anti-patterns:

  • Equal-weight tables where row 1 looks identical to row 50
  • Badges that all look the same regardless of severity
  • Dense pages where the user has to mentally sort what matters

Reference: Wiz Cloud Security UX — known for making complex security feel approachable.

Source: Sergey feedback #7-10 — Deloitte feedback on complexity, day-1 analyst productivity, "WOW effect."

3. No Jargon Without Justification​

If a term requires explaining to a systems integrator or CISO, either replace it or add inline context. The product should not require a glossary.

Test: Read every label, title, and badge aloud to someone who has never used SecurityV0. If they ask "what does that mean?", it fails.

Currently passing:

  • "Unowned Sensitive Access" (cluster name — immediately clear)
  • "3 autonomous identities accessed sensitive systems 681 times — none have an assigned owner" (verdict sentence — no jargon)

Currently under review:

  • "Authority path" — is there a term that doesn't require explaining?
  • "Evidence pack" — how do we define this in plain English?
  • "Egress" — say "outbound data flow" or "sends data to"
  • "Scope drift" — say "permissions expanded beyond original grant"

Rule for evidence labels: Use plain English, not grades. "Execution Confirmed" / "Previously Active" / "Standing Authority" — not A/B/C.

Source: Sergey feedback #11-13 — terminology challenge, plain English labels, evidence pack definition.

4. Remediation Must Be Safe to Follow​

Remediation guidance must acknowledge that the fix might break something. Never present a remediation as "just do this" without stating what could go wrong.

Test: Would a partner feel confident telling a client to execute this remediation? Would they feel embarrassed if it broke a production service?

Rules:

  • Every remediation action names the specific object to change (not "restrict access" — which access, where, how)
  • Every action acknowledges potential business impact ("restricting this may stop the AI Triage workflow — verify with the platform team")
  • The risk is in the change, not just the static state. LLM access might be the automation's purpose — the finding is that the access expanded without approval
  • Actions are sorted by priority. No score bars or numbers — the sorted order IS the priority
  • Actions are deduplicated across clusters. If the same fix addresses 3 problems, say so once

Source: Sergey feedback #14-20 — remove scores, business impact caveat, risk is in the change, atomic/clear/actionable remediation.

5. Partners Sell the Report, Not the Tool​

The platform is the engine. The report is what partners package, brand, and present to their clients. Executive output quality directly determines partner revenue.

Test: Can a Deloitte manager take the assessment report output, put their logo on it, and present it to a Fortune 500 CISO without rewriting it?

Rules:

  • The platform UI stays precise and technical — that's for analysts
  • Reports and digests use business language — that's for CISOs and partners
  • Same data, different presentation layer. Never dumb down the platform to make reports work.
  • Cover page: "[Client Name] — Exposure Assessment by SecurityV0" — simple, no jargon
  • Top risks in absolute terms, not just grouped by cluster
  • Include responsible role ("IAM team" / "Platform Security") in executive summaries

Source: Sergey feedback #21-24 — channel strategy, markdown is fine, report template updates.

6. Don't Add What Hasn't Been Asked For​

Show restraint. Every feature added is complexity the user must navigate. If there's no direct feedback requesting it, hold.

Test: Has a customer, partner, or evaluator specifically asked for this? If the answer is "no but it seems useful," hold.

Currently held:

  • Last-refresh indicator changes — "no direct feedback yet"
  • Risk-reduction tracking — "need to see accepted ways, research Wiz first"
  • Promoting path details into cluster view — "risk turning it into a task list with noise"
  • Effort/complexity estimates — "if we can't confidently assess, drop it"

Anti-patterns:

  • Adding graph visualizations because they look impressive (CISOs won't use them)
  • Adding telemetry-style metrics to a governance product
  • Adding features to match competitors without validating demand

Source: Sergey feedback #25-28 — scope control, don't overengineer, don't turn into telemetry product.

How to Use These Principles​

During Implementation​

Before writing code, ask: which principles does this change serve? If it doesn't clearly serve at least one, reconsider.

During PR Review​

sv0-blue and all reviewers should check PRs against these principles. Add to the review checklist:

  • Principle 1: Does every user-facing text finish the sentence?
  • Principle 2: Is the visual hierarchy clear? Most important thing most prominent?
  • Principle 3: Any new jargon introduced? Any existing jargon that could be simplified?
  • Principle 4: Does remediation guidance acknowledge what could go wrong?
  • Principle 5: If this is report/digest output, would a partner use it as-is?
  • Principle 6: Was this requested by a customer/partner, or are we guessing?

During Agent Reviews​

When running review agents (CISO, SecOps, UX, etc.), include these principles in the prompt as evaluation criteria. The agents should score against these, not just their own frameworks.

Updating These Principles​

These are not permanent. They evolve with customer feedback. When a principle is proven wrong by real usage, update it. Add the date and the reason.

Open Questions (Pending Resolution)​

QuestionOwnerStatus
Should "authority path" be renamed? What to?Sergey + partner feedbackResearch needed
How to define "evidence pack" in plain English?Product teamNeeds proposal
Top risks: per-cluster or flat ranking?SergeyNeeds decision
Can we reliably estimate remediation effort?EngineeringTest with real data
Delta badges: keep, remove, or reframe?SergeyNeeds decision