MDR Compliance Requirements: What to Actually Validate When Choosing a Provider
Table of contents
Most MDR compliance reviews check the wrong things. SOC 2 logos and ISO badges tell you controls existed at audit time. They do not tell you whether access to your data is logged, how quickly critical vulnerabilities in the vendor’s own infrastructure get patched, or whether their incident response SLA aligns with your GDPR notification window. This is the validation layer most procurement processes skip.
MDR providers operate inside your perimeter with privileged access to the same systems attackers specifically want to reach, network logs, endpoint telemetry, incident data, and threat intelligence. The compliance validation that gets them through the door needs to match the risk they represent once they are in.
In practice, three gaps come up consistently. Providers certified for SOC 2 Type I but not Type II. US-based certifications that don’t address GDPR or other international requirements. And access control documentation that reads like a policy statement rather than a description of actual technical controls.
Here is what to look for — and what to push back on.
Why the certifications themselves aren’t enough
SOC 2 Type II is the starting point for any MDR provider handling enterprise security data. Type I certifications only verify that controls existed at a specific moment. Type II validates that those controls operated effectively over a sustained period — typically at least six months. Always request the full audit report, not just the summary letter. The report will show scope limitations, qualified opinions, and any areas where controls were weaker than the headline certification implies.
ISO 27001:2022 demonstrates a comprehensive Information Security Management System. The current version of the standard, updated in 2022, covers 93 controls across four themes: Organisational, People, Physical, and Technological. If a vendor references “114 controls across 14 domains,” they are describing the outdated 2013 version — organisations were required to transition by October 2025. Ask which version they are certified against and when certification was last renewed.
PCI DSS becomes relevant when an MDR provider monitors payment processing environments or handles cardholder data during incident response. For service providers — the classification that applies to most MDR vendors — Level 1 status applies to organisations processing or transmitting over 300,000 card transactions annually. This is a different threshold from the merchant classification of 6 million transactions, and it matters if a vendor is misrepresenting their compliance level.
For global deployments, GDPR Article 28 requires data processing agreements and privacy impact assessments for any provider handling EU customer data. HIPAA Business Associate Agreements mandate specific controls for healthcare implementations. FedRAMP authorisation is required for US government deployments.
The simple rule: request current certification documents with visible audit dates and scope definitions. A compliance claim on a marketing page is not the same thing.
What data protection controls actually need to look like
MDR providers collect data that frequently contains personally identifiable information, intellectual property, and operational details. How that data moves between collection and deletion is where most real compliance gaps live — not in the certification headline.
Encryption standards should cover data in transit (TLS 1.3 or higher) and data at rest (AES-256). More importantly, the key management architecture should separate customer encryption keys from provider access. Ask how this is implemented technically. “We use encryption” is not a sufficient answer.
Data residency matters more than it used to. European customers often need processing to remain within EU boundaries; financial services organisations may need data confined to specific countries. Get written confirmation that data residency commitments extend to backup and disaster recovery infrastructure, not just primary storage.
Access logging is where compliance audits often find their most useful evidence — and where MDR vendors are most likely to produce vague answers. Ask to see a sample access log structure and ask how long access records are retained. The specificity of the answer will tell you whether the capability is genuine or notional.
Other privacy controls worth verifying include data minimisation policies, purpose limitation (data used only for agreed security services), automated purging at the end of retention periods, and documented data portability procedures for when contracts end.
Infrastructure security: the questions that don’t appear on standard checklists
Network segmentation in multi-tenant MDR platforms should implement genuine logical separation between customer environments. Ask for architecture documentation showing how that separation works — not a verbal assurance that it does.
Cloud security deserves particular attention. Misconfigured cloud storage is one of the most common sources of security data exposure, and it is a risk that sits entirely with the MDR vendor’s configuration choices rather than with the underlying cloud provider’s compliance certifications. Those two things are not the same. Request the vendor’s own cloud security assessment results.
Endpoint controls on analyst workstations are frequently overlooked in vendor evaluations. The laptops that process your security alerts need managed device controls, application restrictions, and privileged access management. A compromised analyst workstation can expose multiple customer environments simultaneously.
What independent security validation should look like
Self-reported compliance certifications establish a baseline. External validation provides evidence that controls actually work under pressure.
Annual penetration testing by a named, qualified third party should cover external network testing, internal network assessment, and social engineering evaluations targeting MDR analysts. Request the full report — findings, severity ratings, and remediation evidence. A one-page summary is not sufficient.
Vulnerability management programmes show how a provider handles weaknesses in their own infrastructure. Monthly scanning and quarterly assessments are a reasonable baseline. Ask specifically about mean time to remediate critical vulnerabilities — the answer separates providers who take their own security seriously from those who treat internal patching as a lower priority than customer work.
Red team exercises are not universal, but for enterprise MDR contracts covering sensitive environments — government, financial services, healthcare — they are a reasonable ask and worth requesting evidence of.
Incident response: their problem becomes your compliance obligation
An MDR provider experiencing a security incident affecting their own infrastructure creates a direct regulatory risk for your organisation. Their incident response maturity is your compliance concern, not just theirs.
Incident classification systems should define severity levels and response timelines clearly, with critical incidents involving customer data triggering immediate notification. Ask what “immediate” means contractually. If it is not defined in hours and backed by an SLA, push for it to be.
GDPR’s 72-hour notification requirement for data protection incidents means your contract needs to specify how the provider’s notification timeline aligns with your own regulatory obligations — including who prepares the notification and what information they must provide. Generic breach notification language is not enough. Industry-specific requirements for HIPAA, financial services, and government contracts add further obligations that need to be addressed explicitly, not covered by a catch-all clause.
How CybelAngel fits into MDR vendor evaluation and ongoing risk
One area that standard MDR procurement checklists consistently miss is the external attack surface of the vendor themselves. Before you sign a contract — and throughout the engagement — it is worth being able to answer: what does this provider’s external exposure look like? Have any of their credentials appeared in data breaches?
CybelAngel’s Attack Surface Management module gives you an outside-in view of any organisation’s exposed infrastructure, misconfigured assets, and publicly visible vulnerabilities — including prospective vendors — before they ever access your environment.
Our Credential Intelligence module detects compromised credentials linked to any domain across dark web sources and underground forums. If an MDR provider’s analyst accounts are circulating in underground markets, that is intelligence you want before granting them privileged access to your network.
For ongoing third-party risk management after contract signature, our Dark Web Monitoring capability tracks mentions of your vendors and your data across sources that inside-out security operations can not reach by design. You can also explore how we approach data breach prevention and cyber threat intelligence across the full external attack surface.
FAQs
Type I certifies that security controls exist at a single point in time. Type II validates that those controls operated effectively over a sustained audit period — typically six to twelve months. For MDR providers handling ongoing security operations, Type II is the relevant standard. Always request the full audit report rather than the summary letter.
ISO 27001:2022 is the current version, covering 93 controls across four themes. Certifications against the 2013 version (114 controls, 14 domains) are no longer valid — organisations were required to transition by October 2025. If a vendor references the older control count, ask when they last renewed their certification.
For service providers, Level 1 applies at 300,000 card transactions annually — not the merchant threshold of 6 million. Level 1 service providers must undergo an annual assessment by a Qualified Security Assessor. If a vendor cites the merchant threshold for their own classification, that is worth questioning directly.
At minimum: the full SOC 2 Type II audit report with a named assessor, current ISO 27001 certificate with version and scope clearly stated, the most recent penetration test report, data processing agreements covering your geographic requirements, and a written description of access logging and data retention procedures.
External attack surface scanning gives you an outside-in view of a vendor’s exposed assets, misconfigured infrastructure, and credential exposure — the same view an attacker would have. It covers risks that self-reported compliance certifications don’t, and it takes hours rather than months to produce useful results.
CybelAngel is an external threat intelligence platform, not an MDR provider. We give organisations visibility into threats and exposures that originate outside the perimeter — including vendor risk, exposed credentials, data breaches, and attack surface exposure. Many organisations use CybelAngel alongside an MDR provider to cover the external blind spots that inside-out security operations miss by design.
Want to understand how external threat intelligence fits into your broader security stack? Read our guide to cyber threat intelligence or get in touch with our REACT team to talk through your specific environment.
About the author
