The Trust Score: one number for the boardroom, six components for the operator
One number between 0-100, updated every 30 minutes from live data. Transparent formula, reproducible via inputs_hash, ready for your quarterly reporting. No black-box marketing number.
Security is hard to report to a board. "We had 247 alerts this quarter" says nothing. "We are NIS2 compliant" is a claim without measurability. "We patched three critical CVEs" lacks context.
What a board member wants to know is simple: are we better or worse secured than last month? And how do I know?
The monsys Trust Score gives one answer to that question: a number between 0 and 100, updated every 30 minutes based on live technical data. Not a yearly assessment, not a subjective rating — a reproducible number with a transparent formula.
The Trust Score is the first thing you see — one number, 7d/30d evolution, breakdown per component.
What the Trust Score measures
The score is a weighted average over six components:
| Component | Weight | What it measures |
|---|---|---|
| Patch hygiene | 30% | Open CVEs, weighted by EPSS exploit probability and age |
| Agent health | 20% | Are all servers active and up-to-date? |
| Secrets exposure | 15% | Open security findings (SUID, world-writable, weak SSH configs) |
| Configuration drift | 15% | Binary changes (process DNA) and config deviations from baseline |
| EAT discipline | 10% | Do Emergency Actions execute successfully, or fail? |
| Evidence continuity | 10% | Is there uninterrupted audit evidence for the past 12 months? |
Why transparency matters
Some "security score" products use a black-box algorithm. You get a number but no idea how it was computed. That makes improvement impossible — you don't know where to work.
The monsys formula is fully documented. You can compute exactly why your score is 73 instead of 85. That makes it a management tool, not a marketing number.
Example: your Trust Score drops from 81 to 74 over two weeks. You open the breakdown:
- Patch hygiene: -9 points (three new Critical CVEs on npm dependencies, EPSS > 0.3)
- Evidence continuity: stable
- Configuration drift: -2 points (one process DNA mismatch on a staging server, 48 hours unresolved)
Your action: fix the three npm dependencies and investigate the staging server. Then the score climbs back.
Per-agent Trust Score: see where the wheels come off
Tenant total is for the boardroom. For the operator you want to know: which server is dragging the score down? Click on a host to see its individual Trust Score:
Per agent you see the six components + the top 3 issues pulling the score down. Directly actionable.
Centrality weighting: not every server counts equally
A failing control on a load balancer handling all production traffic is more dangerous than the same control on a test server no one uses.
The Trust Score accounts for this via betweenness centrality — a graph theory concept measuring how central a node is in the network. The CentralityRefreshWorker recomputes this hourly over the topology graph:
- A chokepoint server (load balancer, VPN gateway, database) with high centrality counts up to 2× heavier in the score
- An isolated test server with low centrality counts less
SPOF pressure (Single Point of Failure) is automatically captured in one number. No manual risk weighting needed.
Blast Radius per server: how many other systems are affected if this one is compromised? That same centrality weighs into the Trust Score.
Bootstrap mode: honest for new tenants
A new tenant by definition has no 12 months of audit continuity. That would make its score artificially low.
The bootstrap model redistributes the weight of evidence continuity during the first three months:
| Tenant age | Evidence-continuity weight | Redistributed to |
|---|---|---|
| < 30 days | 0% | Patch hygiene +5%, agent health +5% |
| 30-90 days | 5% | Distributed across other components |
| ≥ 90 days | 10% (full) | — |
The dashboard shows a blue banner while bootstrap mode is active. You know the score is temporarily weighted differently.
Maintenance-aware: planned downtime is not weakness
If you schedule a kernel update and a server temporarily goes offline, you don't want a score dip. The agent health component explicitly excludes servers within an active maintenance window from the heartbeat penalty.
Planned downtime ≠ unhealthy. Your NIS2 reporting does not get a dip because you ran an update.
Compliance erosion: catch silent degradation early
Compliance is not static. A backup worker that crashes, a certificate scanner that fails, a log pipeline that empties — these create no alert but quietly degrade your compliance posture.
The compliance erosion worker takes a daily snapshot of the evidence count per control. When a control loses more than 50% of its evidence vs seven days ago, an alert is raised in category compliance.erosion.
Per framework — NIS2, ISO 27001, CRA — you see which controls are passing, partial or failing. Compliance erosion is flagged separately.
That is the difference between discovering missing compliance evidence before the audit, or during.
How to use the Trust Score in the boardroom
The Trust Score is not a security verdict — it's an operational KPI. You use it like MTTA/MTTR: as a measurement indicating whether you're moving in the right direction.
Quarterly reporting: "Our Trust Score rose from 68 to 79 this quarter, driven by an improvement in patch hygiene (+11 points) through the rollout of automatic OS updates. Evidence continuity now sits at 100% after 12 months of uninterrupted monitoring."
Incident context: "After the security incident on March 14, our Trust Score dropped from 74 to 61. We patched the open CVEs and resolved the configuration drift in the two weeks after. The score is now at 78, higher than before the incident."
Peer-to-peer comparison (anonymous): Not available in monsys — we don't publish benchmarks. But the absolute scale (0-100) gives an internal reference: a score below 60 means there are structural shortcomings that need attention.
Reproducible via inputs_hash
Each Trust Score snapshot has an inputs_hash — a SHA256 over all measurements that fed the score. That makes the score reproducible: given the same inputs, the formula always produces the same number. An auditor can recompute why the score was X on a specific day.
What the Trust Score is not
Not a certification. A score of 85 doesn't mean you're NIS2 compliant. It means your security measures are in good shape across the six measured dimensions.
Not an external benchmark number. We don't compare your score with other organisations. That would suggest false precision.
Not a static verdict. The score changes every 30 minutes. Yesterday's score describes yesterday's situation.
Not a replacement for a risk analysis. The Trust Score is an operational KPI, not a strategic risk analysis. For a complete risk analysis, you need additional work.
The Trust Score is documented at docs.monsys.ai/en/security/trust-score. First five servers free: monsys.ai/en/signup.