Every incident raised for you and the full investigation behind it, your reports, your threat hunts and your service levels. Tasks the SOC raises are answered in the portal, and anything you want looked at is raised there too. Live, and out of your inbox.
Most of what a managed service sends you arrives as email, and email is where a question goes to get lost — answered to one person, forwarded to three, and impossible to find when it matters. Tasks, tickets and enquiries all sit on the incident they belong to, and so do the answers.
When an investigation needs something from you — a confirmation, an approval, a question only your team can answer — it arrives as a task and you reply to it there. No thread, no forwarding, and no working out which version of the answer is the current one.
Something you want looked at goes in directly and reaches the same SOC that handles everything else. You are not composing an email and hoping it lands with somebody who is on shift.
A question about a particular incident attaches to that incident, so the answer sits with the evidence rather than in somebody’s inbox. Whoever reads the case in six months gets the exchange with it.
A mobile app alongside the portal, so something raised out of hours reaches the person who needs to see it where they actually are rather than waiting for a laptop to be opened.
Four real positions, not a colour and a date.
Everything raised for you and where each one is up to — waiting, being investigated, with an analyst, or closed — with the service level met or missed against each one. Closed incidents stay on the page so you can see the whole run.
A verdict that hides its limits asks you to assume the rest.
One incident, start to finish: executive summary, technical detail, the decisions taken, the entities involved, the evidence behind them — and the limitations of the investigation, written into the report rather than left out of it.
What ran, in what order, and how long each step took.
Every step the investigation ran, in the order it ran them, with the gap between each one. Identity classification, source IP discovery, prior occurrences, reputation enrichment, host review — each one a card you can open.
We looked, nothing matched, and here is the record of it.
What we went looking for in your organisation, whether it was scheduled or you asked for it, what each hunt queried and what it returned — including the ones that came back clean, which stay on the page as the record that somebody looked.
A feed you have to triage yourself is work, not intelligence.
Reporting that reaches you because it touches your sector, your region or software you actually run — with a plain statement on the page that a match is not an incident.
Named accounts watched on a schedule rather than only when something fires.
The accounts under standing watch, how often each was checked, what the checks found, and the point at which a watch became an incident.
The portal serves every customer from one platform, so the honest question is what stops one tenant reaching another. The answer is architectural rather than a matter of care.
No. A ticket records that something was raised and who holds it. The portal carries the investigation itself — the steps that ran, in order, with the evidence each one returned and the reasoning that reached the verdict. The incident list is the way in, not the product.
Yes. An incident appears when it is raised and moves through the same states the SOC works to: waiting to be picked up, being investigated, with an analyst, closed. You are watching it happen rather than reading about it afterwards.
The email tells you an incident exists and what was decided. The portal carries everything behind that decision: every step, every entity, the evidence, the timeline with the seconds between each stage, and the limitations. The two are the same incident at different depths, and the email links to it.
Yes. A full case exports as DOCX or PDF, the incident list exports as CSV, and any individual incident has a link you can send to somebody internally. Reporting you can put in front of a board or an auditor without anyone reformatting it first.
Every customer-facing read is filtered to the organisations the caller is entitled to, by a mechanism that fails closed — a query that cannot prove its tenant scope does not run. An automated test fails the build if portal code can reach internal authentication or internal permission resolution, so it is a specification rather than a habit. There is no cross-customer learning: no training, no fine tuning, no embedding of your data.
Both, and they are on separate tabs so neither hides the other. The timeline shows every step the investigation ran and the gap between them; the report shows what each step returned and how the evidence reached the verdict. The close-or-escalate decision is made by policy and by your own decision templates rather than by the model, and on the managed service a senior analyst signs it off by default.
Access is managed per organisation, so you decide who sees it. It is usually the people who would otherwise be forwarded the email — the security lead, the IT manager who has to act on a containment, and whoever answers for security at board level.
No. The portal is how the managed service is delivered rather than a module sold beside it. Every customer has it.
An hour with a SOC analyst, in the product rather than in a deck: a real investigation opened up step by step, the timeline behind it, and the tasks and replies that would otherwise have been an email thread.
