The Command Center is the screen SITEY opens on. It gathers the platform’s core counters, findings by severity, monitored assets, scanner runs, remediation tasks, patch jobs and the people working them, into one aggregation computed on your own database, so you can tell in about ten seconds whether your security posture moved in the right direction this month.
The problem
Most security teams already have the data. What they do not have is one place where it agrees with itself. The web scanner reports severity as a CVSS number, the network scanner reports it as a word, the agent-based checks report something else again. Someone exports three CSVs, normalizes the severity column by hand, pivots them in a spreadsheet, and by the time the deck is ready for the Monday meeting the numbers are two days old.
The cost shows up in specific ways.
- Nobody can answer “are we finding faster than we are closing?” without rebuilding the trend by hand.
- Nobody knows which host is carrying the most findings until someone sorts a spreadsheet.
- Scans that died halfway through still show as “running” for weeks, quietly inflating the sense that scanning is covered.
- When a director asks for a single number that describes risk, the honest answer is a shrug, because every team member computes it differently.
How it works
- One aggregation request, run on your data
Opening the dashboard issues a single call to the platform’s aggregation endpoint. That endpoint runs the counting, grouping and trend building inside your installation, against your database, and returns one payload. The browser does not pull thousands of raw records and add them up client-side, and building this view makes no outbound request, so no finding leaves your infrastructure in order to produce the dashboard.
- Severity is normalized before anything is counted
Every finding’s severity passes through a normalization step that maps vendor-specific labels to a common Critical / High / Medium / Low / Info scale, and converts numeric CVSS scores into the same bands, 9.0 and above becomes Critical, 7.0 and above becomes High, and so on. Within the dashboard the severity totals, the risk pie and the risk score all count the same way, regardless of which scanner produced the finding. Other modules apply their own severity rules to the same records, so use the Command Center as the reference point when you need one consistent set of figures.
- Stale scan state is reconciled on load
Before the counts are returned, scans still marked “running” more than two hours after they started are moved to a timeout state. OpenVAS is deliberately excluded from that rule, because a legitimate OpenVAS run can take far longer. Timed-out scans are then left out of the success-rate calculation, so the scanner health figure is based on runs that actually reached a completed, failed or stopped state rather than on sessions that silently died.
- Twelve months of history is rebuilt from timestamps
Monthly series for new findings, scans started, tasks created and tasks completed are built by bucketing each record’s own timestamp. Nothing needs to be pre-aggregated or scheduled, so the trend lines are correct from the first day you import data, including data that predates your deployment.
- The page renders progressively and degrades honestly
While the aggregation runs, the layout appears as skeleton placeholders rather than a blank screen. Each widget has its own empty state, so a fresh install shows a readable dashboard instead of a wall of zeros and broken charts. The patch metrics strip stays hidden entirely until your first patch job exists.
What you can do
A score from 0 to 100, weighted by severity mix rather than raw count, banded as Healthy, Moderate or Critical. It is calculated across every finding on record, including ones already resolved, so it describes the severity profile of your estate rather than the size of your open backlog.
Total, Critical, High, Medium, Low and Resolved finding counts side by side, plus a severity distribution as both a donut and ranked bars. The severity figures are cumulative totals across all stored findings, with the resolved count shown alongside them.
New findings per month on one trend chart and completed remediation tasks per month on another, to see whether intake and closure are moving together.
Switch the throughput chart between scans started, findings recorded and tasks created, to compare scanner activity against the work being opened on the same timeline.
A success-rate ring backed by completed, failed and stopped run counts, plus the number of scans running right now.
Your protected surface broken down into agents that checked in recently, discovered hosts and domains, with each one’s share of the total.
Identifies the hosts carrying the most findings, banded by finding concentration. The ranking uses the total number of findings recorded against each host, not open findings only.
Ranks the top vulnerability types across your estate and shows which scanner tool is actually producing your findings.
Average task completion time in hours and days, and task closure rate against an 85% target.
Scores your average task completion time against a fixed 72-hour reference. It is derived from that average rather than from per-task deadlines, so treat it as a trend signal, not as an audited count of missed deadlines.
A per-person breakdown, open, in progress, resolved and false positive counts per assignee, alongside a contribution leaderboard.
Recent scans, recent findings and recently completed tasks in one chronological list.
A recent work queue table filterable by scans or findings, showing owner, status and last update for each item.
Total jobs, awaiting approval, applying, succeeded and awaiting retest, visible as soon as automated patching is in use.
Who it is for
Start their shift here, because the activity feed and work queue show what changed since yesterday without opening five modules.
Use the asset risk list and scanner health ring to see which hosts need attention and whether scan coverage is actually working.
Use the risk score, the monthly finding and task-completion trends and the average completion time as a standing status report, the same figures every week, computed the same way every time.
Use the workload matrix to see who is overloaded and who has capacity before assigning the next batch of findings.
Use the resolution-time and closure-rate figures to show that remediation is being tracked and measured. The per-task records behind those figures live in the task module.
Why it matters
The direct saving is the weekly consolidation ritual: exporting scanner results, normalizing severity by hand and rebuilding a spreadsheet. That work disappears, because the same aggregation runs on demand every time the page loads.
The larger saving is in decisions that stop being guesses. A monthly intake line that climbs while task completion stays flat is an argument for more remediation capacity that a manager can act on. An asset risk list that puts one host far above the rest tells you where a single afternoon of work removes the most exposure. An average completion time drifting above 72 hours tells you remediation is slowing down before anyone has to explain it in an audit.
And because the dashboard applies one deterministic severity mapping to every finding it counts, the totals, the pie, the risk score and the trends on this screen all agree with each other, whichever scanner produced the data.
One screen, one way of counting, every week.
Works with
The Command Center reads from the rest of the platform rather than holding data of its own. Severity counts, monthly finding trends and asset concentration come from Vulnerability Lifecycle. Scanner health, throughput and detection sources come from Scan Management. The workload matrix, closure rate and completion time come from Task Management. The patch metrics strip reflects jobs created by Patch Management. When you need a document you can send, Reporting builds one from the same underlying records.
Frequently asked questions
Does the dashboard update by itself?
It builds a fresh snapshot each time you open or reload the page. The aggregation runs server-side against your live database at that moment, so the figures are current as of that load. There is no background polling, so if you leave the tab open all afternoon, reload it before you quote a number.
Can I click a figure to see the records behind it?
Not from the dashboard itself. The Command Center is a read-only overview; to work on individual items you move to the vulnerability list, scan detail or task pages, which carry the filtering and bulk actions.
Does every user see the same numbers?
The dashboard aggregates across the whole installation, so the totals are organization-wide for anyone who can open it. Per-user scoping, seeing only the findings assigned to you, lives in the list and task modules, not in this overview.
What does it look like before we have any data?
Readable. Each chart and list has its own empty state with a short explanation instead of a broken axis, and the patch metrics row does not appear at all until your first patch job exists. As scans land, the widgets fill in on the next page load with no configuration step.
The Command Center is included in every SITEY deployment. There is no separate analytics tier and no per-seat charge for viewing it. See pricing for the monthly and lifetime options, then install it in your own infrastructure and point it at your first scan.