Is Your MDR Doing Enough? An MDR Coverage Assessment

How to understand what your provider covers, find gaps in your security operations, and decide what your business needs next

You have an MDR provider. They monitor your environment, investigate alerts and send reports. When something suspicious happens, someone is supposed to respond.

That can create a reasonable sense that the monitoring part of cybersecurity is covered.

The term Managed Detection and Response, however, does not describe one uniform service.

One MDR may primarily monitor endpoint detection and response, or EDR, across laptops and servers. Another may also collect information from Microsoft 365, identity systems, firewalls, cloud infrastructure, email and other security tools.

Response can vary just as much. One provider may investigate suspicious activity and notify your IT team. Another may have authority to isolate a compromised computer, disable an account, revoke an active session or block malicious activity before someone inside your company approves the action.

Both may legitimately call their service MDR.

The real question is whether the service you have matches the service you think you have, and whether it covers the cybersecurity risks your business expects it to cover.

A useful MDR assessment should tell you what the provider is responsible for, what technology and activity it can actually see, what threats it is prepared to detect, what happens when it finds something and how you know those capabilities are working.

It should also show you where the MDR stops.

Your provider may be doing exactly what you hired it to do while asset visibility, vulnerability remediation, identity security, cloud monitoring, recovery, executive reporting or other important work sits outside its scope.

That may be completely appropriate. Someone still needs to own those responsibilities, or leadership needs to make a conscious decision to accept the risk.

If you cannot verify that something is covered, do not assume it is.

About the author: Wil Klusovsky is CRO at viLogics, where he helps organizations connect cybersecurity risk to operational resilience, business continuity, and executive decision-making.

Why we use NIST CSF 2.0 as the foundation

This guide uses the NIST Cybersecurity Framework 2.0 as a reference for the outcomes a cybersecurity program should accomplish.

NIST CSF 2.0 organizes cybersecurity around six functions: Govern, Identify, Protect, Detect, Respond and Recover. The framework describes cybersecurity outcomes without requiring specific products or technologies, and it was designed for organizations of different sizes, sectors and levels of maturity.

That makes it useful for this exercise.

NIST does not tell you that your company needs EDR, SIEM, ITDR, NDR, XDR or a particular MDR provider. It gives leadership a structured way to ask whether the outcomes the business needs are actually being handled.

NIST Organizational Profiles use a similar idea. An organization can document its current cybersecurity posture, define the target posture it needs, then compare the two to find gaps and prioritize improvement.

We can apply that thinking to MDR and security operations:

What do we have today? What does our business need? Who owns the difference?

This is not a NIST assessment or certification exercise. NIST is the background framework that helps us make sure we are asking about the right responsibilities. I'm just sharing this so you know the assessment here is rooted in more than "a good idea." 

What does “enough MDR” actually mean?

Start with the business.

Which systems keep your company operating? Where does sensitive data live? Which identities could give an attacker significant access? Which technology supports revenue, production, finance, communications or client delivery?

Then examine whether your security operation has the visibility, context and authority needed to protect those things.

Eight areas deserve attention:

Your contract may answer some of these questions. A meaningful review usually requires going further.

First, do you know what needs to be protected?

Before comparing MDR coverage, make sure you have a reasonably accurate picture of the environment the provider is supposed to monitor.

Most organizations have a good handle on their managed laptops and servers. The harder part is everything that has accumulated around them.

Cloud workloads, SaaS applications, network equipment, service accounts, vendor connections, employee-owned devices, IoT, operational technology, old systems and internet-facing assets can all become part of the environment. 

Ask whether you can identify what exists, who owns it, where it is, whether it is still needed and how important it is to the business.

You should also be able to identify new or unknown devices when they appear and determine which assets are outside your current security monitoring.

If you cannot do that confidently, you may have an asset visibility problem before you have an MDR problem.

An MDR can only monitor the systems and information available to it. An unmanaged cloud workload, forgotten server or unknown connected device may sit completely outside the service you are paying for. When we do an asset discovery engagement we often a 2x-3x discovery of assets vs what a client tells us they think they have. In addiction you need to know which systems are most critical to the business so you can prioritize protection and recovery investment. 

How to verify it

Compare your asset inventory with other sources of information available to you: endpoint management, EDR, network discovery, cloud accounts, vulnerability scanners and security platforms.

Look for discrepancies.

If one system says you have 480 endpoints and the MDR reports 423 protected endpoints, the right question is not whether coverage is 88%. More importantly: 

What are the other 57?

They may be retired assets, duplicates, unsupported systems or devices you did not know existed. You need to find out.

Map what your MDR can actually see

Once you know what exists, map that environment against your MDR coverage.

A simple table is enough to expose assumptions quickly:

This exercise often reveals the difference between having MDR and understanding the actual monitoring coverage behind it.

Endpoint and server visibility

EDR is at the center of many MDR services, so start by determining which endpoints and servers are actually monitored.

Ask whether all expected laptops, desktops and servers are enrolled. Find out how the provider identifies sensors that stop reporting, whether older operating systems or specialized equipment are excluded, and who owns those exceptions.

How to verify it: Request an endpoint coverage and sensor-health report. Compare it with your asset inventory and investigate the differences.

Identity visibility

Attackers do not always need to compromise a traditional endpoint. A stolen or abused identity may provide access to email, cloud applications, administrative systems and sensitive data. Credential abuse showed up 39% of breaches in 2026. 

Ask whether your MDR monitors the identity platforms your business depends on. That may include Microsoft Entra ID, Active Directory, privileged accounts, authentication activity and administrative changes.

Some MDR services include strong identity threat detection capabilities. Others remain primarily endpoint-focused.

How to verify it: Ask which identity sources are connected, what identity behaviors the MDR watches for and for examples of incidents those integrations can detect. Confirm that the integrations are actively reporting.

Cloud and SaaS visibility

Moving a workload or application into the cloud does not automatically place it inside your MDR's monitoring scope.

Ask specifically about the platforms your organization uses, including Microsoft 365, Azure, AWS, Google Cloud and business-critical SaaS applications.

How to verify it: Request the list of connected data sources and confirm that logs are actively being received. Ask how the provider knows when an integration stops sending information.

CISA and its partners recommend logging activity such as user actions, administrative changes and network activity across servers, firewalls, endpoints and cloud services, with enough information to support monitoring and incident response.

Don't forget about in house and hosted applications as well. You need visibility into those vulnerabilities especially for critical apps running the business or feeding critical systems. 

Email visibility

Email can provide an attacker with credentials, malicious files or a way to manipulate financial and business processes.

Find out whether your MDR receives information from your email security systems and what the provider can detect from it. You also want to know if there are protections in place beyond spam filters, such as can they prevent phishing links from being activated? 

Having an email security product does not mean your MDR is monitoring it.

Network visibility

Firewalls, VPNs, DNS services and other network infrastructure can provide evidence that is difficult to see from an endpoint alone. These devices can be managed by you or an MSSP, it's as critical to ensure they are maintained as much as it's critical that you monitor the traffic on the network and going through these devices.

Ask which network sources are monitored and whether the MDR can identify suspicious activity moving between systems or communicating outside your environment. 

OT and IoT visibility

Manufacturers, healthcare organizations, logistics companies and many other businesses operate technology that cannot be managed like a typical corporate laptop.

Production equipment, building systems, cameras, warehouse devices, medical devices and other connected systems may require different security technology or operating procedures.

If those systems matter to the business, document whether your security operation can see them. If it cannot, determine the risk and decide whether additional OT and IoT coverage is warranted.

Can your MDR detect the threats that matter to your business?

Collecting security data gives the MDR something to analyze. You still need to understand what it is capable of detecting.

Ransomware is an obvious concern, but the discussion should also cover compromised credentials, privilege escalation, lateral movement, persistence, malicious cloud activity, data theft and other attacker behavior relevant to your organization.

MITRE ATT&CK provides a useful reference because it documents tactics and techniques observed in real-world adversary behavior.

Be cautious with claims such as “We have 95% MITRE ATT&CK coverage.”

MITRE specifically advises organizations against chasing 100% ATT&CK coverage. Different organizations face different threats, and detecting one implementation of a technique does not mean every variation will be detected. MITRE recommends focusing on the techniques relevant to the organization and understanding what the defensive coverage actually means.

A more useful question is:

Which attacker behaviors are most relevant to our environment, and how would you detect them?

The provider should be able to explain what information supports those detections and how the detections are tested. Evidence might include detection validation, safe simulations, sample investigations, ATT&CK mappings or security exercises appropriate for your environment.

You are looking for evidence that the provider can turn the data you send it into useful detection and investigation.

This is all about context.  

Does your security operation have enough context to know what matters first?

Security teams rarely have a shortage of findings.

There are endpoint alerts, vulnerability scans, identity events, firewall logs, cloud findings and tickets from multiple tools. A growing company can generate more security work than its internal team can realistically investigate or remediate at once.

The harder problem is deciding what deserves attention first.

A vulnerability on a forgotten test machine may represent very different risk than the same vulnerability on an internet-facing server that supports a critical business application.

An alert involving a standard employee account may warrant different urgency than similar activity involving a privileged administrator.

Context helps make those decisions.  Industries are often targeted with similar attacks because they use similar tools. Some vulnerabilities will be more impactful than others based on how your organization is set up.

Useful context can include the importance of the asset, whether it is exposed externally, who has access to it, the sensitivity of the data involved, whether a vulnerability is being actively exploited, what other systems it can reach and what would happen to the business if the system were unavailable.

This context allows you to focus time on the things that can truly hurt your business and not waste time and resources on efforts that don't move the needle on reducing risk. 

Are vulnerabilities actually being managed?

A vulnerability scanner can identify weaknesses. Vulnerability management continues after the scan.

Ask what happens when your provider finds 500, 5,000 or 50,000 vulnerabilities.

Who reviews them? How are they classified? How does the organization decide which ones need immediate attention? Who creates the remediation work? Who patches or reconfigures the system? Who tracks exceptions? Who confirms that the issue was actually resolved?

Some providers run scans and deliver a report.

Others help prioritize findings, create remediation work, integrate with IT ticketing or patch-management processes, track remediation and verify closure.

Those services produce very different outcomes.

NIST describes enterprise patch management as a process that includes identifying, prioritizing, acquiring, installing and verifying patches, updates and upgrades. That last step matters. Work is not complete simply because a ticket says a patch was deployed.

And don't let the word "enterprise" fool you, everyone needs to do this. Smaller businesses have a much higher chance of total collapse from a breach, this means identifying things that can impact the business quickly and acting on them. 

Look at how vulnerabilities are prioritized

A severity score is useful information, but it should not be the only information.

Consider whether your vulnerability process takes into account factors such as business criticality, external exposure, privilege, available mitigations and evidence that attackers are actively exploiting the vulnerability.

CISA's Known Exploited Vulnerabilities catalog is one example of useful threat context. CISA adds vulnerabilities based on evidence of active exploitation and recommends that organizations prioritize timely remediation of those vulnerabilities as part of their vulnerability management programs.

The objective is a manageable workflow that connects findings to action:

Discover → classify → prioritize → assign → remediate → verify

If your process regularly produces large scan reports but there is no clear ownership for what happens next, the problem is no longer vulnerability discovery.

It is remediation management.

Ask how vulnerability management connects to IT

Security may identify the problem while IT has the access, maintenance windows and operational knowledge required to fix it.

That division of responsibility can work well when the handoff is clear.

Ask whether findings automatically create tickets, whether remediation priorities are shared with IT, how overdue findings are escalated and how the security team verifies closure.

If your vulnerability provider, MDR, IT team and patch-management process all operate separately, important work can disappear between them. That is one reason some organizations manage IT and security under one operating model.

This is where an MDR review starts becoming a broader security operations conversation.

What happens after your MDR detects something?

Imagine your MDR detects activity suggesting that an employee account has been compromised.

Does the provider investigate the activity and call your IT team? Can it disable the account? Can it revoke active sessions? Can it isolate the employee's laptop? Can it block a malicious IP address or domain? Which actions require someone inside your organization to approve them?

Those answers should be documented before an incident.

Know the provider's response authority

Some decisions are straightforward. You may be comfortable allowing your MDR to isolate a typical employee laptop when evidence reaches an agreed threshold.

Other actions may carry significant operational consequences. Disconnecting a production server could stop manufacturing, interrupt client services or affect a business process that leadership considers critical.

Document what the MDR can do independently, what it can do under preauthorization and what requires explicit approval.

Then confirm that the people responsible for making those decisions can actually be reached when the incident happens.

Understand what “response time” means

A provider advertising a 15-minute response time may be promising that an alert will be acknowledged within 15 minutes. That does not tell you how long investigation or containment will take.

Break the process into actual events:

Alert received → investigation begins → decision made → containment occurs

Ask which part of that process the service commitment measures. Then review actual performance.

For high-severity cases during the previous quarter, how long did investigations take? When containment was necessary, how quickly did it occur? Were service commitments missed? What changes outside normal business hours?

There is no universal number that is right for every company or system. The response objective should reflect how quickly a particular threat could affect the business.

Where does your MDR stop after containment?

Suppose your MDR identifies a compromised server and isolates it successfully.

The immediate threat may be contained, but the business still has work to do.

Someone may need to rebuild the server, restore data, determine whether sensitive information was accessed, preserve evidence and decide when the system can safely return to production. Legal counsel, cyber insurance, leadership or outside incident responders may also need to become involved.

Your MDR may provide some of those services. Your internal team or another provider may own them.

NIST separates Respond and Recover within CSF 2.0. Respond covers actions surrounding a detected cybersecurity incident, while Recover covers restoration of affected assets and operations.

Document where your MDR's responsibility ends, identify who takes control next and exercise that handoff before you need it.

Is leadership getting useful security reporting?

Your MDR probably gives you reports.

The question is whether those reports help you run the business.

Ticket counts, alert volumes, response times and SLA performance are useful operational measures. They show whether work is happening and whether the provider is meeting specific service commitments.

Leadership needs additional context.

Are meaningful risks increasing or decreasing? Are important vulnerabilities getting fixed? Are critical systems adequately covered? Are the same problems recurring? Where should the company invest next? Which risks require a leadership decision?

A report stating that the team closed 100 tickets last month tells you something about activity. It does not tell the CEO, CFO, COO or board whether the security program is improving.

Useful executive reporting should show leadership where the business stands and what requires attention next. That could include significant risks, remediation progress, coverage gaps, security incidents, exceptions, compliance obligations, upcoming investments and decisions leadership needs to make.

Your MDR does not necessarily need to provide all of that.

But Someone does.

NIST added the Govern function to CSF 2.0 specifically to give greater visibility to cybersecurity governance, including risk tolerance, roles and responsibilities, policies and the connection between cybersecurity and enterprise risk management.

For a mid-market organization, ownership might sit with a CISO, CIO, IT director, security leader, business executive, vCISO or another person explicitly responsible for the program.

That person should be able to explain the organization's current risks, what is being done about them, where progress is being made, what the next priorities are and where leadership needs to make a decision.

If nobody owns that view, you have found a governance gap.

How to verify it

Look at the last few security reports presented to leadership.

Could an executive use them to understand current cyber risk and make a decision?

Or are they primarily lists of alerts, tickets, vulnerabilities and SLA metrics?

Then identify the person responsible for turning all of that security activity into priorities, accountability, reporting and a roadmap.

If you cannot identify that owner, document the gap.

MDR, EDR, SIEM, ITDR, XDR and SOC: what are you actually buying?

Security terminology can make a simple coverage discussion unnecessarily confusing.

The acronym on the invoice tells you the category of service you purchased.

The coverage review tells you what you actually have.

The 20-point MDR and security operations assessment

Use four answers for each item:

• Covered: You have evidence that the capability exists and applies to the environment that requires it.
• Partially covered: Some systems, threats, actions or conditions are covered, while meaningful limitations remain.
• Not covered: The capability is not currently provided.
• Don't know: You cannot verify the answer.

If you cannot verify an item, mark it Don't know until you can.

Don't turn the checklist into a score

A total score hides too much.

A company could mark 18 of 20 items as covered and still have a serious problem if the two missing items involve privileged identities and containment authority.

Another organization may have several partially covered items that affect low-impact systems and represent risks leadership has deliberately chosen to accept.

Review each gap in context.

More importantly, verify every item marked Covered. A contract promising endpoint monitoring is different from evidence showing that all expected endpoints are enrolled, healthy and actively monitored.

What should you do with the gaps?

For every item marked Partially covered, Not covered or Don't know, decide whether your business actually needs the capability.

If it does, identify who owns it.

Most findings will fall into one of four categories:

Pay closest attention to the unowned gaps.

A consciously accepted risk is a business decision. A risk nobody knew they were accepting is a different problem.

Should you optimize, supplement or replace your MDR?

Finding a gap does not automatically mean your MDR provider has failed.

Sometimes the capability already exists within the current service. A log source may need to be connected, an integration may have failed, endpoint deployment may be incomplete or additional response authority may need to be documented.

Fix the existing service when it can meet the requirement.

Other gaps may require capabilities outside the MDR. You may need stronger asset visibility and exposure management, identity monitoring, vulnerability management, patching, recovery planning or security-program leadership.

In those cases, supplementing a provider that performs its assigned role well may make more sense than replacing it.

Replacement deserves consideration when the provider cannot support requirements your business has decided are necessary. Persistent visibility problems, inadequate response capability, unsupported environments, poor integration or an inability to demonstrate performance are reasonable reasons to evaluate alternatives.

Make the decision based on the outcomes your business needs and the evidence you can verify.

What to ask at your next MDR review

You do not need to turn your next provider meeting into a technical interrogation.

Ask them to walk you through these questions:

1. What are you responsible for?
2. What parts of our environment can you see today?
3. What important parts can you not see?
4. What threats are you prepared to detect with that visibility?
5. What can you do when you find one?
6. What happens to vulnerabilities and other security findings after they are identified?
7. Who owns the work outside your scope?
8. Show us how we can verify each answer.

Then look one level above the MDR.

Do you know what assets you have? Do you have enough context to prioritize the work? Are vulnerabilities making their way from discovery through remediation? Does someone own the broader cybersecurity program? Is leadership receiving information that helps it make better decisions?

The goal is not perfect coverage. It is knowing what your business needs, who owns each responsibility and whether the protections you depend on actually work.

Don't accept cyber risk you didn't know you were accepting.

Want to do a quick self assessment of your cyber risk program?

Take 7 minutes, answer 20 non-technical questions about your program and get an instant Business Cyber Risk Score showing you coverage and gaps across major areas of cybersecurity. You'll also receive a detailed pdf with deeper insights and actions. 

Found a gap?

If this review uncovered missing assets, incomplete visibility or difficulty deciding what deserves attention first, viLogics' Asset Visibility & Exposure Management services are designed to help organizations understand what they have, where they are exposed and which issues deserve priority based on business impact.

If your MDR is performing its role but nobody owns the broader cybersecurity program, Managed GRC and vCISO services can provide program ownership, risk management, remediation tracking and executive reporting.

If you are not sure where the gaps are yet, start with a Cyber Risk Review to understand your current environment, responsibilities and priorities.