How VitalSec works
Follow two examples through the same operating loop: vulnerability remediation and direct control actuation. See how VitalSec observes state, decides what should happen, acts inside customer authority, verifies the result, preserves proof, and measures the change.
Example 01 · Customer-approved software update
Observe → Decide → Act → Validate → Prove → Measure.
This example follows a software update through the six-stage control loop. Customer policy determines which actions can run automatically and which require approval. Each step leaves evidence for the next one.
01 / Observe
A connected vulnerability source reports an affected software version on an endpoint. VitalSec keeps the finding, asset context, and observation time together so the team can establish what is actually present.
Finding + affected endpoint + source evidence
02 / Decide
VUMA checks whether the vulnerability actually applies and how urgent it is. The customer’s policy and maintenance window determine whether the software update can proceed automatically or requires a decision.
Prioritized work + clear approval status
03 / Act
When the update is authorized, VitalSec applies it through Rusty or a connected management tool and records what happened.
Remediation action + recorded result
04 / Validate
The source is read again after the update. The observed version and exposure must support closure. A successful command alone cannot establish that the vulnerability was removed; an unresolved or unavailable result remains visible.
Fresh observation + evidence supporting the result
05 / Prove
Evidence Continuity keeps the original finding, authorization, action, and follow-up evidence connected. An authorized reviewer can trace the reported result to the records that support it.
Connected history + integrity information
06 / Measure
The validated evidence returns to risk measurement. The Risk Compression Engine explains modeled risk direction, while the Risk Compression Index summarizes the current measure when sufficient evidence supports it.
Updated risk context + the drivers behind the change
Example 02 · Control actuation
Observe → Decide → Act → Validate → Prove → Measure.
This path is not patch management. It shows Rusty actuating an approved endpoint control change, VitalSec verifying the state afterward, and Evidence Continuity preserving signed proof of the result.
01 / Observe
Rusty reports that a required endpoint control is off, misconfigured, or outside the customer’s policy state.
Control state + device + source evidence
02 / Decide
VitalSec evaluates the control condition against customer policy, device context, and the authority already granted for that class of action.
Required state + authorization decision
03 / Act
Rusty actuates the approved control change on the endpoint—for example enforcing a security configuration, activating an EDR response, or restoring a required policy state.
Control action + execution record
04 / Validate
VitalSec reads the endpoint again after the action. The control must report the required state before the result is treated as restored.
Fresh control state + verified outcome
05 / Prove
Evidence Continuity binds the original condition, authorization, actuation, and post-change observation into signed proof of what happened.
Source-linked evidence + signed proof
06 / Measure
The verified control state returns to risk measurement so the modeled trajectory reflects the control that is actually operating now.
Updated control health + risk direction
Go deeper
Explore how VUMA handles vulnerability remediation, how Rusty actuates endpoint controls, and how Evidence Continuity preserves the signed proof behind the result.
Discuss your workflow with PatientLock, or review the tools VitalSec can connect to.
