Why alert triage is harder for an MSSP
Alert triage for an MSSP is the same job as in-house triage, done many times over for organisations that each look different. The analyst who opens the queue at night may see a failed sign-in burst from a law firm, a PowerShell alert from a manufacturer and a suspicious mailbox rule from a charity, one after the other. Each needs the customer’s own context to judge, and each customer expects its alerts handled as if it were the only one.
Volume is the obvious pressure. Alerts add up across tenants, and a single noisy rule rolled out to many customers can fill the queue in an afternoon. The less obvious pressure is switching. Every time an analyst moves to another customer, they have to recall a different estate, different naming, different normal behaviour and different people to call. That switching costs time and causes mistakes.
The work also has to be shown. A customer pays for a service it mostly does not see, so the provider needs records and reports that prove the alerts were looked at properly, and in words the customer understands.
How to keep customer data separate
Separation is the foundation of trust with customers. Each customer’s alerts, logs, investigation records, notes and reports should live in its own space, with access limited to the people assigned to that customer. An analyst working on one customer should not be able to search another’s logs by accident, and nothing learned from one customer’s data should leak into another’s verdicts.
Separation has to cover more than storage. Connections to each customer’s SIEM or EDR need their own credentials. Settings such as notification channels, ticket queues and escalation contacts must be per customer. The audit trail should show, per customer, who looked at what and who decided what. If an AI is involved, the context it remembers from corrections must stay inside the customer it came from.
- A separate tenant per customer: data, people, connections and settings
- Per-customer credentials for each integration, never shared
- Analyst access granted per customer, and reviewed regularly
- Corrections and remembered context scoped to one customer
- A per-customer audit trail you can hand over on request
How to manage per-customer context and tuning
Most wrong verdicts at a provider come from missing context. An admin tool that one customer uses daily looks like an attack at another. A server named “fs02” might hold board papers at one customer and test files at the next. Capture this context once, during onboarding, and keep it where the analyst sees it when an alert arrives.
Useful context is specific. Which machines matter most and what business process each one serves. Which accounts are service accounts and what they normally do. Which tools are approved, which scanners run and when, which change windows are planned. Who to call for an urgent finding, and who should not be woken for a medium one.
Tune rules per customer, not globally. A rule that is noisy at one customer because of a legitimate tool should get an exception scoped to that customer and that tool, with a note saying who approved it and why. Global exceptions made to quiet one customer’s queue are how real attacks at other customers go unnoticed.
How to keep verdicts consistent across customers
Customers compare notes, and they notice when similar alerts get different treatment. Consistency does not mean identical verdicts, because context differs. It means the same method, the same standard of evidence and the same verdict categories, applied by every analyst on every shift.
Write the method down. A short playbook per common alert type, listing the questions to ask and the data to check, helps new analysts and keeps experienced ones honest. Use a fixed set of verdicts, such as real attack, suspicious, harmless, authorised and unsure, with a definition for each. Sample closed alerts each week and have a senior analyst check them against the method.
An AI analyst can help here, because it applies the same investigation approach on each alert regardless of the hour or how busy the queue is. It still needs each customer’s context, and its verdicts still need review.
How to write reports customers can read
Most customers of an MSSP are not security specialists. The person reading the monthly report may be an IT manager, a finance director or a practice owner. Write for them: what happened, what it meant for their business, what you did, what they should do, and what you need from them.
For a significant finding, a short written report beats a forwarded alert. Say which machine and which business process were affected, how sure you are and why, what the evidence showed in plain words, and the recommended next steps with a named owner. Keep the technical detail in an appendix for their IT team.
- What happened, in one or two plain sentences
- What it put at risk, in business terms
- How sure you are, and the evidence behind it
- What you recommend, and who should do it
- Anything you need from the customer, such as missing logs
How triage affects MSSP margins and analyst time
For a provider, analyst time is the main cost of triage, and most of it goes on alerts that turn out to be harmless. Every minute spent re-learning a customer’s environment, chasing context or writing up a routine closure is a minute not spent on the alerts that matter, and a cost that rises with each new customer.
An illustrative example, with assumptions stated: suppose a provider adds a customer whose alerts take, on average, ten minutes each to triage by hand, and that a well-presented AI investigation lets an analyst review and confirm a harmless verdict in a couple of minutes. The time saved per alert is the difference, multiplied by that customer’s alert volume. Run the same sum on your own figures before you trust it; the inputs vary widely between customers.
Look at what drives your costs as you grow. If adding a customer means adding analysts in step, margins stay flat at best. The aim is for the effort per customer to fall as context is captured and corrections accumulate, so experienced analysts spend their time on investigation and customer conversations rather than routine closures.
Where an AI analyst fits in an MSSP
An AI analyst fits at the first look. It collects each customer’s new alerts, investigates them against that customer’s data and context, and hands a person a verdict with its evidence. Your analysts review, correct and decide, and the customer relationship stays with your people.
For this to work at a provider, the platform has to be multi-tenant in a real sense: a tenant per customer, each with its own people, connections, settings and audit trail, and corrections that stay inside the tenant. Check also that usage can be limited per customer, and that reports can be produced per customer for the people who receive them.
Be clear with customers about the AI’s role. Tell them it investigates and recommends, that your analysts review and decide, and where their data is processed. Many will ask, and a clear answer is a reason to choose you.
How armor360 approaches it
armor360 is one platform with a tenant per customer, each with its own people, connections, settings, AI model choice, usage limits and audit trail. It collects alerts from Elastic Security, Splunk, Microsoft Sentinel, CrowdStrike Falcon and Microsoft Defender, investigates each one using the business context recorded for that customer, and gives a verdict with a confidence and cited evidence.
Your analysts agree with a verdict or change it, and corrections are remembered for later investigations about the same customer. Investigations can be shared as reports in HTML, Word or PDF. armor360 takes no response actions: it recommends, and people decide and act. Pricing is by quote, sized to what you protect, with no charge per person.