EDR, XDR, SIEM, SOC and MDR: What They Are and Where an SME Should Start With Detection and Response

Tools: what EDR, XDR and SIEM each see

EDR: a sensor on the endpoint, plus a response button

The US Office of Management and Budget (OMB) memorandum M-22-01, issued in 2021 to implement Executive Order 14028, describes EDR (endpoint detection and response) as combining real-time, continuous monitoring and collection of endpoint data (for example workstations, mobile phones and servers) with rules-based automated response and analysis capabilities; compared with traditional security tools, it provides the visibility needed to respond to polymorphic malware, advanced persistent threats (APTs) and phishing^[1]. The memo governs US federal agencies, but its description is a good way to understand this class of product.

The big difference from traditional antivirus is the "response" part. In Microsoft Defender for Endpoint, for example, an administrator can act on a single device from the console: collect an investigation package, run an antivirus scan, restrict app execution, or isolate the device. Isolation cuts the device off from the network while keeping its connection to the Defender service so monitoring continues, which stops the attacker from controlling the host, exfiltrating data or moving laterally^[2]. EDR can also be set to block on detection: in its analysis of ransomware as a service (RaaS), Microsoft recommends running EDR in "block mode" so Defender for Endpoint can block malicious artifacts even when a non-Microsoft antivirus does not detect the threat or when Defender Antivirus is running in passive mode^[3].

XDR: joining up signals from endpoints, identity, email and cloud

XDR (extended detection and response) is a product category that extends the EDR idea to other data sources, and each vendor defines its own scope. Taking Microsoft's description as an example, Defender XDR coordinates detection, prevention, investigation and response across endpoints, identities, email and applications, joins alerts, suspicious events and impacted assets from each product into a single incident, and can automatically apply containment when high-confidence signals from several sources line up^[4].

This is exactly what EDR alone cannot see. When an attacker uses a stolen password or session cookie to sign in to the company's cloud mailbox from their own computer, the EDR on company endpoints does not see that sign-in; only identity and email signals show something is wrong. See Infostealers and leaked credentials and Compromised company email account for how this works.

It also has limits. Microsoft notes that Defender XDR only correlates signals from the Microsoft security products the customer has licensed and enabled, and its built-in cross-product threat hunting covers 30 days of raw data^[4]. In this example, XDR's view centers on one vendor's products, and it does not replace long-term log retention.

SIEM: central log collection, correlation, alerting and retention

The NIST glossary, citing SP 800-92, defines SIEM (security information and event management) as "a program that provides centralized logging capabilities for a variety of log types"^[5]. In practice a SIEM also does correlation, alerting and retention: the 2024 logging guidance from Australia's ASD, the US CISA, FBI, NSA and other agencies notes that centralizing logs in a SIEM lets an organization compare activity against a business-as-usual baseline and spot deviations and cyber security events^[6].

A SIEM is vendor-neutral: firewall, VPN, AD, cloud service and EDR data can all be fed into it, and it is often where logs are kept for the long term. The price is that someone has to write and tune the detection rules. The same guidance makes two further points: a SIEM holds a wealth of information and can become a single point of failure for detection, which makes it an attractive target, so it should be hardened and segmented from the general IT environment; and logs should be filtered before they are sent to a SIEM or XDR so only the most valuable ones go in, to avoid extra cost or capacity problems^[6].

People and services: SOC, MDR and MSSP

SOC: a team and a set of processes, not a product

The UK National Cyber Security Centre (NCSC) explains that SOCs (security operations centers) vary widely in scope, but most are responsible for detecting and responding to cyber attacks; prevention does not always work, and the SOC's role is to limit damage by detecting and responding to attacks that get past preventative controls^[7]. The core SOC functions NCSC lists are threat intelligence, threat hunting, detection content development, engineering (maintaining tools and onboarding logs), incident handling and incident management^[8], all of which are work done by people. In other words, a SOC is not a product you install: EDR, XDR and SIEM are the SOC's tools, and the SOC is the people and processes that use them.

NCSC also notes that most SOCs outsource some of their operations, even if only the signatures their tools use for detection, and that outsourcing can make sense for a function that is seldom used or that the organization lacks the resources to build^[8].

MDR: outsourced detection and response

MDR (managed detection and response) is a service in which a provider's analysts watch your alerts, investigate and respond for you. Microsoft's description of its own MDR service is a useful example: analysts manage the customer's incident queue around the clock, triage and investigate on the customer's behalf, and either take action or guide the customer's team through the response; the service is positioned to augment the customer's SOC rather than replace it; and for supported third-party products it only provides response guidance^[9]. The example highlights the two things to pin down when buying: what data the provider can see, and how far it can act for you.

MSSP: a broader managed security service

A joint advisory from the cybersecurity agencies of the US, UK, Australia, Canada and New Zealand defines a managed service provider (MSP) as a business that delivers, operates or manages ICT services for customers under a contract such as a service level agreement, and notes that these services can include cybersecurity^[10]. An MSSP generally means an MSP focused on security services, ranging from managing security devices to log monitoring; MDR centers on detection, investigation and response.

None of these labels has a fixed specification. Two services both called MDR may differ completely: one only sends alert emails, the other can isolate a host. The contract matters more than the label. The same advisory recommends that contracts state whether the provider or the customer owns responsibilities such as hardening, detection and incident response; that the provider explain which services the customer is buying and which it is not; and that the contract specify how and when the provider will notify the customer of incidents affecting the customer's environment^[10].

Detection needs someone to act on it: why 24/7 matters

Tools only produce alerts, and an alert is only worth something if someone handles it at the right time. Sophos analyzed 661 incident response and MDR cases it handled between November 2024 and October 2025: 88% of ransomware payloads were deployed outside business hours, and 79% of data exfiltration also took place outside business hours^[11]. These are one vendor's own cases, but they show clearly the risk of having nobody on duty out of hours.

Detection is not the same as stopping the attack. Microsoft notes that when antivirus detects and blocks one of an attacker's tools, the attacker often just switches tools, modifies the payload or tampers with the security products in the way; such detections can give a SOC a false sense of security, so alerts on tools like Cobalt Strike need to be investigated and acted on quickly to contain a human attacker before ransomware is deployed^[3]. In other words, even an alert marked "blocked" needs someone to decide whether the attacker is still in the network.

Round-the-clock staffing is expensive. NCSC notes that a 24/7 SOC needs significantly more staff than a 9-to-5 operation with out-of-hours on-call, that a 24/7 SOC is much less effective if other IT teams only work 9-to-5 with no on-call arrangements, and that high-priority out-of-hours alerts can be routed to on-call staff^[8]. OMB's M-22-01 likewise requires agencies to make sure EDR is appropriately resourced and staffed, with funding to maintain the tool through its lifespan^[1].

For an SME, the question is not "should we build our own SOC?" but "when an alert goes off at 3 a.m., who picks it up and who can make decisions?" The answer may be an MDR provider, internal on-call staff, or both. Also make sure that when the provider escalates in the middle of the night, someone on your side has the authority to decide whether to shut down a server or disable an account. For what to do once an incident is underway, see The first 24 hours of a suspected breach and After ransomware encrypts your files; adding a "Saturday 2 a.m. EDR alert" scenario to a tabletop exercise is a good way to check whether this path actually works.

What Taiwan's rules say

Regulations Governing the Classification of Cyber Security Responsibility Levels

Article 11 of the Regulations Governing the Classification of Cyber Security Responsibility Levels (資通安全責任等級分級辦法) requires government agencies and specific non-government agencies to carry out the items in Appendices 1 to 8 according to their responsibility level^[12]. Under the current appendices, as amended on 7 January 2026^[12]:

• Levels A and B: government agencies (Appendices 1 and 3) and specific non-government agencies (Appendices 2 and 4) must all build and continuously operate a "security monitoring and management mechanism" (資通安全監控管理機制) and an "endpoint detection and response mechanism" (端點偵測及應變機制), and submit monitoring and detection data in the manner the competent authority designates. Monitoring must cover the endpoint detection and response mechanism and each security protection measure, plus logs from directory service systems and core information systems and records from ICT equipment.
• Definition of the endpoint detection and response mechanism: the appendices define it as protection that provides active scanning and detection on endpoints, vulnerability protection, behavioral analysis of suspicious programs or anomalous activity, and display of the related threat level.
• Deadlines: both must be in place within one year of the level first being approved or changed; for items added or changed by an amendment to the appendices, the deadline runs from the date the amendment took effect (Article 11).
• Other protection measures: at levels A and B, security protection also includes intrusion detection and prevention, and a web application firewall for core systems that provide external services; level A additionally requires defenses against advanced persistent threats.
• Levels C, D and E: none of them requires the monitoring mechanism or the endpoint detection and response mechanism. At level C (Appendices 5 and 6), security protection means antivirus software, a network firewall and, where the agency runs a mail server, email filtering; at level D (Appendix 7), antivirus software and a network firewall; level E (Appendix 8) requires only general security awareness training.

For specific non-government agencies, the central competent authority for the sector may also set additional required items within the scope of the regulations^[12]. For which companies count as specific non-government agencies, and why vendors serving them may be asked to meet the same requirements, see Taiwan's Cyber Security Management Act. Even if you are out of scope, the appendices are a useful reference: endpoint detection and a monitoring mechanism are required from level B upwards, while levels C and below treat antivirus and a firewall as the baseline.

Cybersecurity Control Guidelines for Listed and OTC Companies

The Taiwan Stock Exchange (TWSE) revised its Cybersecurity Control Guidelines for Listed and OTC Companies (上市上櫃公司資通安全管控指引) in November 2026. Article 19 lists eight security controls: antivirus software, a network firewall, email filtering for companies with email services, intrusion detection and prevention, a web application firewall for core systems that provide external services, defenses against advanced persistent threats, plus an "endpoint detection and response mechanism (EDR)" and a "cyber threat detection and management mechanism (SOC)"^[13]. The comparison table of amendments shows that SOC was already listed in the pre-amendment Article 18, while EDR is new in this revision, and the explanatory note says the change took account of the classification regulations' requirements on endpoint protection and threat detection^[14].

Article 24 of the same guideline requires monitoring of information systems and equipment, covering authentication records such as failed sign-ins, sign-ins outside working hours and multiple users signing in successfully from the same source IP, plus protection of the logs; Article 33 requires procurement documents to state a service level agreement (SLA), security requirements and the right to audit the contractor's security; and Article 34 requires the company, when an outsourcing relationship ends, to confirm that the contractor returns, hands over, deletes or destroys the data it held under the contract^[13]. When outsourcing a SOC or MDR, Article 24 works as a checklist for monitoring scope, and Articles 33 and 34 as a checklist for contract terms. Article 44 states that listed and OTC companies may adopt the guideline in proportion to their industry, size and cyber risk^[13]; for a chapter-by-chapter summary, see the TWSE cybersecurity control guidelines.

Choosing and buying: a staged path and the questions to ask

A suggested order

This is a suggested order for SMEs without a dedicated security team; each step builds on the data from the one before:

1. EDR on every endpoint and server, with block mode and tamper protection on: the five countries' cybersecurity agencies recommend that all organizations, whether on their own or through an MSP contract, implement endpoint detection and network defense monitoring^[10]. Microsoft found that in almost every ransomware incident it observed, at least one system involved had a misconfigured security product that let the attacker disable protection or evade detection, and that initial access was often a legacy system with no antivirus or EDR^[3]. So the point is not just buying EDR but coverage and configuration; for tamper protection and block mode, see How ransomware gets into a company. EDR is not a cure-all either: some infostealers evade it, as explained in Infostealers and leaked credentials.
2. Add identity and email signals: bring Entra ID or Google Workspace sign-in and audit logs, and email protection alerts, into the same console; if your endpoints, identity and email all sit on one vendor's product line, XDR is the most direct way to combine these signals. For baseline account and email settings, see Microsoft 365 and Google Workspace security baselines.
3. Centralize and keep logs: collect firewall, VPN, AD and cloud audit logs in a SIEM, or at least in one secure central store; the five-country advisory recommends that all organizations keep their most important logs for at least six months^[10]. For which sources to collect, see the logging strategy.
4. A 24/7 monitoring and response service: once the data sources are in place, have an MDR or MSSP look across endpoints, identity and logs together and handle out-of-hours alerts. You can use MITRE ATT&CK to check which attack techniques the provider's detections cover.

This order is not fixed. Some EDR vendors offer their own MDR service (such as the Microsoft example above^[9]); if nobody at your company can handle alerts out of hours, bring step 4 forward, start with "EDR plus MDR", and add identity, email and logs to the service scope over time.

Questions to ask before signing an MDR contract

These questions draw on the five-country joint advisory and the Canadian Centre for Cyber Security (CCCS) guidance for consumers of managed services^[10][15], and can go straight into an RFP and contract:

• Is it really 24/7? Who watches alerts at night and at weekends, and how quickly do they respond? CCCS recommends that the SLA specify expected turnaround times, communication channels, escalation processes, performance metrics and penalties for missing turnaround times; it also warns that a provider serving many customers may leave what you consider an emergency sitting in its queue^[15].
• Who can isolate a host or disable an account, and how fast? Agree in advance what the provider may do without asking, for example isolating ordinary workstations directly but phoning before touching critical servers, and write it into the contract and operating procedures. In Defender for Endpoint, for instance, high-impact response actions can be restricted on high-value assets to avoid business disruption, and isolating a server running Hyper-V blocks network traffic to all of its virtual machines^[2]. The provider's accounts should also enforce MFA, be limited to the systems the provider manages, and stay out of internal administrator groups^[10].
• Which data sources are covered? Only the provider's own EDR, or identity, email, firewall and cloud as well? Some services only give response guidance for third-party products rather than acting for you^[9]. Does detection rely only on signatures of known malware, or also on behavioral detection^[15]?
• Where is the data stored, and for how long? In which country or region the logs and telemetry are stored, and whether the retention period can meet your own retention policy and regulatory requirements^[15].
• What is reported, and how are you notified? How and how quickly incidents are notified; whether you can see the provider's presence, activities and connections in your environment^[10]; and whether the provider can analyze incident patterns over time to find recurring root causes^[15].
• What happens when the contract ends? Who owns the data, whether it can be exported in non-proprietary formats, and how the provider deletes it^[15]; also remember to disable the provider's accounts and remove its agents. The joint advisory specifically warns that disabling MSP accounts is easily overlooked when a contract terminates^[10]. Listed and OTC companies can check this against Articles 33 and 34 of the TWSE guideline at the same time.

Action checklist

• Sort your current security tools and services: which are tools (EDR, XDR, SIEM), which are people and services (SOC, MDR, MSSP), who watches each one's alerts, and who picks them up out of hours.
• Confirm EDR covers every workstation and server, including legacy systems, with block mode and tamper protection on; check monthly for endpoints that have stopped reporting.
• Write a response authority table: which devices the provider or on-call staff may isolate directly, which need sign-off and from whom, and who decides on disabling accounts or shutting down servers.
• Bring Entra ID or Google Workspace sign-in and audit logs, and email protection alerts, into a single console.
• Keep your most important logs centrally for at least six months, then fill the gaps using the logging strategy.
• If nobody can handle alerts out of hours, evaluate EDR plus MDR; compare providers against the questions above and write the answers into the SLA.
• Government agencies and specific non-government agencies at level A or B: confirm the deadlines for the monitoring mechanism and the endpoint detection and response mechanism. Listed and OTC companies: check Articles 19, 24, 33 and 34 of the TWSE guideline.
• Add a "Saturday 2 a.m. EDR alert" scenario to a tabletop exercise and test whether the path from provider escalation to internal decision to host isolation actually works.
• If you need outside help with investigation and response, see our incident response service.