AI Daily Summary is the single screen your team opens first thing in the morning. It answers one question, what changed in our vulnerability posture since yesterday, and what needs attention today, from live data in your own database, and it can turn that picture into a written report and, once you have configured an SMTP server, a morning email to your administrators.
The problem
Most security teams already have the data. What they do not have is a daily habit that reads it. Someone opens the vulnerability list, filters to critical, sorts by date, squints at how many arrived overnight, checks whether anything has been sitting open too long, tries to remember what last week looked like, and then rewrites roughly the same paragraph into a chat channel or a management email. It takes a real bite out of the start of the day, it is done differently by whoever happens to be on shift, and it silently stops happening the week everyone is busy.
The consequences are predictable. A critical finding that landed at 02:00 is noticed at 14:00. A critical that has been open for nine days is nobody’s problem because nobody counted its age. Management asks “are we getting better or worse?” and the honest answer is a shrug, because nobody kept last week’s number. And when the team does write a summary, it reflects only the vulnerability table, not SLA pressure, not exploit availability, not who is overloaded, not which scanners are actually covering anything.
Without SITEY
- Someone opens the vulnerability list, filters to critical, sorts by date and squints at how many arrived overnight
- A critical that lands at 2am is not noticed until someone happens to look, often hours later
- Nobody kept last week’s number, so “are we better or worse” gets a shrug
- The morning summary reflects the vulnerability table alone, not SLA pressure, exploit data or who is overloaded
With SITEY
- The dashboard opens with live counts already computed from your database, nothing to filter or sort by hand
- An hourly background job raises a new-critical notice as soon as one is recorded
- This week’s new findings are compared to last week’s with an explicit percentage and a stable, increasing or decreasing verdict
- The written report draws on SLA compliance, exploit intelligence, agent health and workload, not the vulnerability table alone
How it works
- The day is counted from live data
Opening the page runs a set of queries against your vulnerability records in real time, with nothing cached from a nightly job. You get four numbers immediately: open critical findings, open high findings, everything newly recorded in the last 24 hours, and everything closed in the last 24 hours. Open means status open or in progress, so the counts reflect actual outstanding work rather than historical volume. The closure figure is counted from the archive timestamp, so a resolved finding appears in it once it has been archived.
- The trend is computed, not eyeballed
The module counts new findings over the last seven days and over the seven days before that, and expresses the difference as a percentage. Movement beyond ten percent in either direction is labelled increasing or decreasing; anything inside that band is called stable, so normal week-to-week noise does not get reported as a crisis. Both weeks are drawn as a two-bar comparison so the direction is readable at a glance.
- Priority findings and warnings surface on their own
Below the counters the page lists the most recent open critical and high findings with their risk level, name, target host and port, and CVSS score. Alongside it runs a notification feed fed by a background job: every hour the platform looks for critical findings recorded in the last 24 hours that are still open and raises a new-critical notice, and it looks for critical findings that have been open longer than seven days and raises an SLA warning that states how many days the finding has been sitting, covering up to ten ageing findings per run. Notices are deduplicated per finding and per recipient, so the same critical does not reappear every hour. The background job is enabled by default and can be switched off per deployment through the worker role setting.
- You ask for the written report when you want it
One button turns the raw numbers into prose. Before calling the model, the platform assembles a broad organisational context from across the database: prioritised findings, top targets, assignment suggestions, statistics, trends, SLA compliance, agent health, task workload, scanner coverage, exploit intelligence, compliance status, top CVEs, remediation velocity, notification history, scan history, AI usage, comments, risk assessments, asset inventory and agent inventory. The model is then asked for a structured brief: an executive risk assessment, what is urgent today, up to five actions for the week, trend analysis with a projection, a team workload read, compliance risks, and a closing recommendation.
- Every report is recorded
Each generated report is written to the activity log with its timestamp, the model that produced it, its completion status and an opening excerpt of the text. The full narrative is shown in the Analysis tab at the moment it is produced; the history entry keeps the first part of it rather than the complete document. The History tab shows your last twenty daily reports, and a separate panel summarises your last thirty days of AI activity, how many operations ran in total and how they split across daily summaries, single triage, detailed analysis and batch triage.
These notices are written to active administrator accounts, so an account needs the administrator role to see this feed.
Each of those context blocks is collected independently, so if one data source fails the rest of the report still gets built.
What you can do
See open critical and high counts, plus 24-hour intake and 24-hour closures, without building a filter or a saved view.
Compare this week’s new findings against last week’s with an explicit percentage and a stable / increasing / decreasing verdict.
Read the newest open critical and high findings with host, port and CVSS in one table.
Receive automatic new-critical notices and SLA warnings for criticals open longer than seven days, with the age stated in days, in administrator accounts.
Be told when a critical finding matches an already-learned remediation script, including that script’s recorded success rate, so you know a fix may already exist.
Generate a written daily brief covering risk posture, today’s urgent items, the week’s actions, trend projection, workload and compliance exposure.
Have the summary emailed each morning to every active administrator who has an email address, as a formatted HTML report, once an SMTP server is configured and the send hour is set in your deployment configuration.
Review the last twenty generated reports with their timestamps, models and status.
Track thirty days of AI activity volume broken down by operation type.
Check total active findings and the last 24 hours of AI request volume at the bottom of the page.
Who it is for
SOC analysts and duty shifts get a fixed starting point for the day, and on administrator accounts a notification feed that flags overnight criticals without a manual sweep. System administrators see which hosts and ports are carrying the newest high-risk findings, and whether a known remediation script already applies. Security managers and CISOs get the week-over-week direction in a form that can be forwarded as-is, plus a written assessment that draws on SLA and exploit data rather than raw counts alone. Compliance officers get an explicit compliance-risk section in the generated report and a dated record of each report in history. Team leads get the workload read and the ageing criticals that indicate where work is stuck.
Why it matters
The everyday saving is the stretch of each morning someone spends reconstructing a picture the database can produce instantly, before counting the same work repeated across shifts. The larger saving is detection lag. A critical that arrives overnight is picked up by the next hourly run of the notification job instead of whenever someone next runs a filter, and a critical that has quietly aged past a week raises its own warning instead of waiting for a quarterly review to discover it.
It also changes the conversation with management. This week’s intake set against last week’s, with the percentage difference stated, is a sentence that survives a board meeting; “things feel busier” is not. And because the written report draws on SLA compliance, exploit intelligence, agent health and assignment data rather than the vulnerability table alone, it tends to surface the reason behind a number, an overloaded owner, a scanner that stopped reporting, a cluster of criticals on one host, which is the part a manual summary almost always leaves out.
Works with
- Notifications carries the new-critical and SLA alerts this module raises out to the rest of your workflow.
- AI Triage is what turns the priority findings listed here into validated, scored work items.
- AI Operations Log holds the record of every AI operation, including each daily report generated here.
- AI Usage Analytics tracks the AI request volume shown at the foot of this page in more detail.
Frequently asked questions
Does the report generate automatically, or do I have to ask for it?
Both, and they are separate. The dashboard, meaning counts, trend, priority findings and notifications, loads from your database every time you open the page, with no AI involved. The written narrative is generated when you press the button. In addition, a built-in scheduler can produce the daily summary at an hour set in your deployment configuration and email it to active administrators, provided you have configured an SMTP server; the notification job runs hourly. Both background jobs are on by default and can be disabled per deployment. Note that the scheduled morning report is generated once, using the first administrator account that has a usable AI key, and that same text is sent to every recipient.
What happens if we do not configure an AI key?
Everything except the written narrative keeps working. The counters, the week-over-week trend, the priority findings table, the notification feed, the SLA warnings and the history are all computed by direct database queries. Requesting the written report without a configured key returns a clear error telling you the key is missing, rather than failing silently.
Does our vulnerability data leave our servers?
The platform runs entirely in your own infrastructure, and the daily summary is built by querying your own database. The only step that sends anything outward is the written report, which passes the aggregated context to the model endpoint you configured. The platform talks to an OpenAI-compatible endpoint, so the model and endpoint are your choice and can be a self-hosted one. The dashboard itself calls only your own server.
Can I go back and look at an earlier day?
Yes, within limits. The History tab lists your last twenty generated reports with the date and time, the model used, the completion status and the opening excerpt of the report text, so you can trace what was reported and when. What is stored is the beginning of the report rather than the full document, and the numeric dashboard always reflects the current state rather than a past date.
A daily security picture should not depend on whoever remembered to build it.
If you want your team to start every morning from the same set of numbers, and to be told about overnight criticals and ageing SLA breaches without going looking, see the pricing page and deploy SITEY in your own environment.