PRODUCT

Signals & Lifecycle

Ten signal types with severity SLAs, per-tenant lifecycle, and Slack routing.

Book a demo Start free

What it is

TrustVendor monitors ten distinct signal types across the vendor risk surface: breach notifications, CVE disclosures, financial changes, news sentiment shifts, certificate expirations, compliance status changes, data incidents, acquisitions, regulatory actions, and service outages. Each type carries a default severity rating refined by the Triage agent against your relationship context — the data classes, integration scope, and geography you share with that vendor.

Signals are not notifications. A notification fires and disappears. A signal has a full lifecycle: new, acknowledged, investigating, resolved, or dismissed. Each state transition is timestamped and attributed to the user or system that made it. You can attach notes, link related signals, and export the full lifecycle history for audit purposes. When an auditor asks how you responded to a vendor breach notification, you have a timestamped record.

Routing is flexible by design. Signals can be delivered to Slack channels, Jira issues, Linear tickets, Microsoft Teams, PagerDuty, or your own webhook endpoint. Routing rules are per-vendor-group and per-severity, so critical signals for vendors processing PHI go to your security on-call channel while informational signals for low-criticality tools go to a weekly digest.

How it works

Three steps, fully auditable.

01

Detect

The collection plane watches ten distinct source categories continuously. When a monitored source changes, the diff is run through the Extractor and Triage agents to classify the event type, severity, and materiality relative to your relationship profile.

02

Triage

Materiality is assessed against your specific exposure: data classes, regions, integration depth. A subprocessor added in a jurisdiction your SCCs do not cover is urgent. The same change for a vendor you share no data with is informational.

03

Route

Signals are delivered to your configured channels within the SLA for their severity: critical within 15 minutes, high within 1 hour, medium within 4 hours. SLA clock starts from the source event, not from when TrustVendor fetches it.

What you get

Built for compliance teams that have to prove things.

Ten typed signal categories

Breach, CVE, financial, sentiment, certificate expiry, compliance change, data incident, acquisition, regulatory action, outage — each with a default severity and evidence citation.

Severity SLAs

Critical signals reach your channel within 15 minutes of detection. All SLA clock times are from the source event timestamp, not from the crawl timestamp — no hiding latency in the pipeline.

Full audit lifecycle

Every state transition is timestamped and attributed. Acknowledged, investigated, resolved, or dismissed — the record is complete and exportable for your auditors.

Sample

What it looks like in practice.

Signals feed — 3 open
HIGH
Acme Analytics compliance_change

SOC 2 Type II scope reduced — Confidentiality criteria removed from current audit cycle.

2h ago

new
MED
BrightPath Health certificate_expiry

HIPAA BAA attestation expires in 28 days. No renewal evidence detected.

6h ago

acknowledged
CRIT
Openlink Systems breach_notification

Breach notification published. Affected data classes include customer_content.

14m ago

new

Common questions.

How is severity determined?
Default severity comes from the signal type — a breach notification is critical by default. The Triage agent then adjusts severity based on your relationship context: a breach at a vendor with whom you share no data may be downgraded to high or medium. The adjusted severity is what drives your routing rules and SLA clock.
Can I silence signals for specific vendors?
Yes. You can snooze signals for a vendor with an expiry date, dismiss individual signals with a required reason, or configure a minimum severity threshold per vendor group. Dismissed signals remain in the history — they cannot be permanently deleted, which is intentional for audit trail purposes.
What is the difference between a signal and a score change?
A signal is a discrete event with a type, severity, and evidence citation. A score change is a computed outcome that may or may not be caused by a signal. Many signals do not move scores — an outage does not change a posture score. Score changes are tracked separately in the score history timeline.
Do signals work for vendors not in my monitored portfolio?
No. Signals require an active monitoring relationship — a vendor in your workspace. The public graph shows you current posture and assurance scores for any vendor, but signal delivery and lifecycle management are workspace features tied to monitored relationships.

See Signals & Lifecycle on your vendor data.

Book a 30-minute demo. We will run it live on vendors from your register.

We will respond within one business day.