The MDR providers that let you see what their SOC is doing are the ones that work inside your own environment and document every action they take. When detection rules and response actions live in your tenant, you can read them in tools you already use. When the work happens in a provider’s platform, your view depends on its portal and reports.
This page sets out what visibility should cover and what to ask a provider before you sign.
The essentials
- Where the work happens. Work done in your tenant leaves records your team can read.
- What gets documented. Every response action should come with what was found and what was done.
- Who keeps what was built. Detection rules and playbooks in your workspace stay with you.
- What the reports measure. Reports should show outcomes improving over time, beyond activity counts.
Why does visibility into the SOC matter?
You can hand a provider the work of monitoring and response, and the consequence of an incident still lands on your organization. Our post Why You Can’t Outsource Risk makes that case in full.
Visibility is how you hold a provider to the outcome. It lets your team check that tuning is reducing noise, that response is getting faster and that the provider acted the way you agreed. Our post on outsourced SOC activity explains why rising ticket counts can hide a lack of progress.
What should you be able to see?
Detection rules
The analytics rules running against your data, including who changed each rule and why.
Tuning changes
What was suppressed or adjusted to reduce false positives, so you can confirm a real threat was not tuned away.
Investigations
The notes and evidence behind each decision to close or escalate an incident.
Response actions
Every containment step, such as an isolated device or a blocked account, with the time it was taken.
Provider access
Which permissions the provider holds in your environment and a log of what it did with them.
Trends over time
Response times and false positives reported as trends you can compare across periods.
How do the two MDR operating models compare?
Our MDR page describes two operating models. The comparison below shows how each one affects what you can see.
| Question | Work in the provider’s platform | Work inside your tenant |
|---|---|---|
| Where does your log data live? | It moves to the provider’s cloud | It stays in your tenant |
| Where do you see detections and actions? | In the provider’s portal | In your own Microsoft environment |
| What gets installed? | Provider agents on your machines | No agents, with a delegated connection your team scopes and can revoke |
| What stays if you leave? | History and playbooks stay with the provider | Everything built stays in your workspace |
For how shared ownership works when your team and a provider both work in Sentinel, read how co-managed Microsoft Sentinel works.
What should you ask an MDR provider about visibility?
- Can we see your detection rules? Ask where the rules live and whether every change to them is visible to your team.
- What do we receive after each action? Ask for a sample of the notification you would get, including what was found and what your team should review.
- Where does our data go? Ask whether log data leaves your tenant and where it is stored.
- How is your access granted and logged? Ask who sets the permission scope, whether you can revoke it and where the provider’s actions are recorded.
- What stays with us if we leave? Ask whether detection rules and incident history remain in your environment.
- Which trends do your reports show? Ask for response times and false positives over time alongside alert volume.
For the metrics worth asking for, read which SOC metrics show whether risk is going down. For a fuller list of buying criteria, read how to choose MDR for a Microsoft environment.
How does Accelerynt MDR handle visibility?
Accelerynt is one example of the in-tenant model. Our team connects through Azure Lighthouse, a management layer built into Microsoft Azure, so we operate in your environment without holding your credentials.
- You set the access. Your security team defines the permission scope during onboarding and can adjust or revoke it at any time.
- Our actions are logged in your tenant. Everything we do through Lighthouse appears in your tenant’s activity records.
- You see what we see. Detection rules, tuning changes and response actions are visible in your own Sentinel workspace, and our playbooks are published on GitHub.
- You get regular reporting. Monthly operational reports cover what was addressed and what changed, and quarterly maturity briefings show trends and recommendations.
The MDR engagement model explains how our team and yours work in the same environment. If you are weighing SOC as a Service against MDR, read how to choose an outsourced SOC for a Microsoft environment.
If an IT provider also holds access to your environment, read how to verify an outsourced IT provider follows your security controls.
Frequently asked questions
Which MDR providers let you see what their SOC is doing?
Providers that work inside your own environment give you the most direct view, because their detection rules and response actions live in your tenant. Ask any provider where the work happens, what it documents after each action and what stays with you if you leave. Accelerynt MDR works inside your Microsoft tenant through Azure Lighthouse.
Can I see what MDR analysts are doing in my environment?
With an in-tenant provider, yes. You see detection rules and response actions in your own tools, and the provider’s actions are recorded in your tenant’s activity logs.
What should an MDR provider document after an incident?
Each containment action should come with what was found, how access was gained, what the provider did and what your team should review next.
What happens to detection rules if we leave an MDR provider?
It depends on where the rules were built. Rules and playbooks built in your own Sentinel workspace stay with you. In the provider-platform model, history and playbooks stay with the provider, so ask before you sign.