Name the security lane instead of leaving it a bare denial.
The FAQ already says this plainly: no always-on SOC. That answer is honest, but incomplete on its own — it says what does not run without saying what does. This page names the actual lane, and the point past which everything stops being routine.
What actually runs inside the baseline lane.
Useful when a practice wants routine security-baseline upkeep handled on a rhythm, without implying a security-operations capability that does not exist here.
Defender configuration and policy upkeep against an agreed baseline, triage of the monitoring alerts that baseline generates, email-security tuning — anti-phishing, anti-spoofing, and malware-filtering rules — against reported false positives and misses, and scheduled awareness nudges such as phishing-simulation follow-up and password-hygiene reminders, sent through the client's own channel.
A baseline check runs on its agreed cadence and is recorded as pass, fail, or exception; an alert is triaged and either closed as routine or escalated with the observed state attached.
The named product baseline — which Defender and email-security controls are actually in scope — the monitoring tool and alert thresholds, the awareness content and its cadence, and the named owner for anything the baseline flags as a real finding.
Where the lane stops, on purpose.
- Anything resembling an active incidentSuspected compromise, ransomware behavior, or active data exfiltration is not triaged as a routine alert — it escalates immediately, ahead of the rest of the queue.
- Legal or regulatory notification questionsWhether an event triggers a breach-notification duty is returned to the named owner, not decided inside the baseline lane.
- Cyber-insurance and forensic engagementThese bring their own process and often their own named vendor; delivery does not substitute for either.
- A client asking to be called "compliant" or "secure"A passed baseline check is a fact about that check, not a certification. See how baseline reporting can feed a compliance conversation without turning into one.
These are the same safe-stop and exception-note mechanics used everywhere else on this site — a security trigger just moves faster through them.
Who decides what, in the security lane specifically.
| Baseline configuration change | Delivery proposes against the agreed standard; the selling practice approves anything that changes the standard itself. |
|---|---|
| Routine alert triage | Delivery closes or escalates against agreed thresholds — no fresh judgment call per alert. |
| Suspected active incident | Escalates immediately to the named security owner, ahead of the standard exception queue. |
| Awareness content and cadence | Selling practice approves the message and schedule; delivery executes and reports completion. |
Ask these before assuming security is covered.
- Does the baseline name actual products and settings?"Security" without a named baseline is not a scope — it is a mood.
- What exactly triggers the incident-escalation path?Get the trigger in writing before the first alert arrives, not while reading one.
- Who is the named owner once delivery's part of the work is done?A baseline check with no one to receive its findings is just a log file.
- Does the practice still carry its own security judgment?Delivery administers a defined baseline; it does not become the practice's security advisor by default.
See how this lane fits next to the others.
The escalation matrix sets the general pattern this lane follows; the service catalog places baseline work alongside user support and Microsoft 365.