Methodology & Evidence Standards
The EDR Telemetry Project measures exposed endpoint telemetry visibility. It does not measure prevention, detection efficacy, alert quality, managed service quality, or overall product quality.
Scope & Boundaries
What the project evaluates and what it deliberately does not
What We Evaluate
Telemetry visibility exposed to users: raw or near-raw event data that customers and analysts can use to investigate, build detections, and hunt.
What We Do Not Evaluate
A score is a telemetry availability score. It is not a product ranking for protection quality.
Direct Telemetry vs Inferred Activity
Why a direct event matters more than a circumstantial clue
Full credit requires a clear event that directly represents the system action. Related or circumstantial evidence may help an investigation, but it does not replace the direct event for scoring.
| Direct event that counts | Insufficient substitute |
|---|---|
| User creation or modification event | Linux file-attribute changes instead of a user-modification event |
| Scheduled task creation event | Generic cron or process activity instead of a scheduled-task event |
| Handle opening or remote thread event | Generic process-created event |
| Service creation event | Registry change under HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services |
Valid Telemetry Criteria
All conditions must be satisfied for a telemetry event to count
Required conditions
Every criterion must be satisfied for telemetry to receive full validity credit.
Distinct action
Represents a distinct system action, not a generic clue.
Direct collection
Is directly collected rather than inferred from unrelated activity.
Consumer access
Is exposed to the product consumer for search, detection building, hunting, or investigation.
Timely capture
Is automatically collected as the activity occurs or within the agreed near-real-time window.
Investigation-ready
Is explicit enough for investigation and pivoting.
Evidence-backed
Is backed by the executed test, raw evidence, and expected-vs-observed mapping.
In scope
Fits project scope and is not live query, historical backfill, manual collection, or unrelated module output.
Near-Real-Time
Telemetry is available for customer search within 10 minutes by default, unless an engagement explicitly defines a different window.
Consumer Availability
Telemetry must be accessible through the product UI, API, or export without vendor engineering, support-only retrieval, or manual backend extraction.
Status Taxonomy & Scoring
How each telemetry sub-category receives a numeric value
| Status | Value | Meaning |
|---|---|---|
| Yes | 1.0 | Required telemetry is implemented and exposed directly. |
| Via EnablingTelemetry | 1.0 | Telemetry exists only after enabling a built-in setting or feature. Same numeric value as Yes, but not equivalent to out-of-the-box Yes. |
| Partially | 0.5 | Related telemetry exists, but full-credit validity fails because it is incomplete, conditional, subset-only, inconsistent, missing required fields, or related-but-not-direct. |
| Via EventLogs | 0.5 | Telemetry is surfaced through platform-native OS logs rather than independent native sensor collection. |
| No | 0.0 | Telemetry is not implemented or is not exposed in a qualifying way. |
| Pending Response | 0.0 | Status remains unresolved at scoring time and cannot be upgraded without qualifying evidence. |
Evidence Standards
What reviewers need to recheck a status claim
Minimum Evidence
Each direct-test conclusion should be traceable to evidence that can be rechecked.
Absence Findings
A No or absence finding must document what was searched and how. If a vendor disputes the finding, they must identify the specific source, table, or query for a targeted recheck.
Optional Telemetry Governance
How new sub-categories earn score-bearing status
Vendor coverage threshold
New sub-categories are excluded from scoring until they reach 75% implementation coverage across the supported vendor set for the scoped platform.
Only Yes and Via EnablingTelemetry count as implementation coverage. Partially, Via EventLogs, No, and Pending Response do not count toward the threshold unless a future methodology version says otherwise.
Vendor-Assisted Direct Evaluation Workflow
The controlled process for contracted telemetry evaluations
Scope Confirmation
Confirm OS, edition, tenant, product version, sensor version, and sign-off contact in writing.
Test System Setup
Evaluator supplies test systems and installs the EDR agent. Vendor assigns intended policies and tenant-side configuration.
Validation & Sign-off
Vendor validates the setup and gives written readiness/sign-off before testing begins.
Configuration Freeze
Configuration is frozen after sign-off. Material changes require written agreement and may reset the evaluation.
Controlled Execution
Evaluator executes the agreed activity set and collects raw product telemetry.
Event Validation
Each sub-category is validated against the event-validity criteria and assigned a status.
Reporting
Reporting includes category status, scoring, justification, caveats, and review material.
Versioning
This page summarizes methodology version 1.1 dated 2026-04-27. Live links are informational unless an agreement incorporates a later revision.