Vedric is designed for the four roles that use insider-risk tools day to day. Each role needs something different from the same product. This page describes what changes for each role, and what stays the same.
This is the standard insider case. There is no unauthorized access, malware, or credential abuse. A user with legitimate access to their own material changes their activity patterns during their last two weeks. The full timeline is on the Use Cases page. The four cards below show how each role reads the same scenario.
Needs defensible insider-risk coverage without keystroke surveillance.
You answer to a board, an auditor, and a workforce, and each wants something different. The board wants assurance that early insider activity is covered. The auditor wants evidence that the coverage exists. The workforce wants a guarantee that they are not being watched. Most insider-risk tools can satisfy only two of the three.
You can give the board and the all-hands meeting the same explanation. Coverage is built mainly on comparing behavior against each identity’s own long-term baseline. There is one disclosed exception: a bounded PowerShell script preview. A defensible explanation states that exception plainly.
Vedric does not replace your SIEM, EDR, or DLP. It runs alongside those tools and reads activity they were not built to read.
Needs an audit trail and a data collection scope that can be disclosed precisely.
Your regulators want evidence that internal misuse is detectable. Your employment counsel and works council need a precise inventory of what is captured, including the bounded PowerShell preview, before anything goes live.
Most signals are reproducible from behavioral metadata. Where PowerShell script evidence is present, it is explicitly labeled, truncated, and best-effort redacted. As a result, the audit trail and the privacy notice can describe the same actual collection.
Vedric does not replace your existing legal-hold, eDiscovery, or content-DLP processes. When a case requires content review, those tools still do that work. Vedric tells you which cases are worth opening.
Needs a system that does not produce a flood of alerts that must be tuned out by hand.
Rule-pack products ship hundreds of generic detections. All of them fire on day one, and tuning becomes a full-time ticket queue. Within a few months, teams often set up a Slack channel just for muting alerts.
Vedric tunes itself to each environment by learning that environment’s normal activity over time. The alerts that reach you are correlated storylines: multiple independent baselines deviating from normal for the same identity. Tuning becomes a review step.
You still own the runbook. Vedric does not auto-contain, auto-disable, or auto-notify HR. Vedric shows the storyline. Your team decides what to do with it.
Needs the chronology already assembled when a case opens.
After a page, the first hour goes to reconstruction. With a flat event stream, you assemble the sequence of events by hand. The early part of the incident is spent on work the platform should have done before it paged you.
Vedric pages with the storyline already assembled: which identity, which baselines deviated, over which days, and in what order. The case opens with the chronology in place, so the first hour goes to the decision.
Vedric is not a forensic artifact collector and not a memory-image tool. When a case escalates to deep forensics, your existing IR stack still does that work. Vedric shortens the time it takes to decide that a case needs deep forensics.
If you hold one of the four roles above, tell us what you need. Early access requests are reviewed manually. We do not use automated sales sequences.