Measuring XDR Effectiveness

Most XDR programs are graded on the wrong scoreboard: how many data sources are ingested, how many detections fired, how pretty the dashboard looks in the quarterly business review. None of that tells you whether the platform would have caught the intrusion that actually mattered. This article lays out a rigorous, engineering-grade framework for measuring XDR effectiveness — the architecture that makes cross-domain correlation possible, the metrics that actually predict outcomes, and the buyer discipline needed to tell a real detection-and-response capability from a well-marketed log aggregator.

The measurement problem: why most XDR metrics lie

Every XDR vendor ships a dashboard with alert counts, detection rules fired, and a shrinking mean-time-to-detect number trending in the right direction. Almost none of that is a proxy for effectiveness. Alert volume is inversely related to analyst trust — a platform generating ten thousand alerts a day is not ten times more effective than one generating a thousand, it is very likely worse, because the signal-to-noise ratio has collapsed and analysts are triaging by fatigue rather than by risk. Detection rule counts measure vendor content-authoring effort, not coverage of the techniques an adversary will actually use against your environment. And a shrinking MTTD number can just as easily reflect a change in how the vendor buckets alert-to-detection timestamps as it can reflect genuine improvement.

The honest starting point is to separate three distinct questions that get collapsed into one number far too often: can the platform see the activity (telemetry coverage), can it correlate that activity into a coherent story across domains (detection fidelity), and can the organization act on that story fast enough to matter (response velocity). A platform can be excellent at the first and mediocre at the third, and the composite metric will hide that entirely. Effectiveness measurement has to decompose the pipeline stage by stage, or it becomes theater.

This matters more for XDR specifically than for any single-domain tool because XDR's entire value proposition rests on correlation across endpoint, network, identity, and cloud telemetry. A standalone EDR can be evaluated on its own terms — does it catch process injection, does it block a known ransomware binary. XDR's claim is bigger: that stitching four telemetry planes together produces detections none of the individual planes could produce alone. That claim is falsifiable, and it should be tested directly rather than taken on faith. The rest of this piece is about how to run that test, in production, continuously, with numbers you can defend to a CISO or a board.

The XDR reference architecture: what's actually being measured

Before metrics make sense, the architecture they describe needs to be explicit. A production-grade XDR stack has five layers, and effectiveness measurement applies differently at each one.

At the base sits the telemetry collection layer: endpoint sensors (EDR agents capturing process trees, file operations, registry changes, memory events), network sensors (flow records, DNS logs, TLS metadata, packet capture at chokepoints), identity telemetry (authentication events, privilege escalation, token issuance, conditional access decisions), and cloud control-plane logs (API calls, IAM policy changes, workload orchestration events). Above that sits a normalization and enrichment layer that maps disparate log formats into a common schema, resolves entities (a user, a host, a workload, a service account) across sources, and attaches context like asset criticality, vulnerability state, and business ownership. Third is the correlation and detection layer — the actual analytic engine that fuses signals into detections, whether via curated correlation rules, statistical baselining, or machine learning models trained on attack sequences. Fourth is the investigation and triage layer, where analysts (human or automated) build and validate the incident narrative, pull additional context, and decide disposition. Fifth is the response and orchestration layer — the actions taken to contain, eradicate, and recover, whether isolating a host, revoking a token, quarantining a cloud workload, or blocking a network segment.

Each layer has a distinct failure mode, and each failure mode needs its own metric. A telemetry gap at layer one makes everything above it blind regardless of how good the correlation engine is. A schema mismatch at layer two silently drops entity linkages, producing detections that look plausible in isolation but never assemble into a cross-domain story. A correlation engine tuned only on endpoint-heavy attack patterns will underperform against identity-centric attacks like credential stuffing followed by consent-grant abuse in a SaaS tenant, even with perfect telemetry. This is why platforms like Algomox's XDR detection and response capability are architected around explicit entity resolution and cross-plane graph correlation rather than a flat rules engine bolted onto a SIEM — the correlation layer has to be a first-class citizen, not an afterthought.

The four telemetry planes and what breaks when you skip one

XDR's name promises "extended" detection, and the extension is specifically across these four planes. Each plane sees a different phase of an intrusion clearly and is nearly blind to others, which is exactly why correlation across them, rather than depth within any one, is the differentiator worth measuring.

Endpoint telemetry

Endpoint sensors see process creation, parent-child relationships, command-line arguments, DLL loads, memory injection techniques, and file system activity. This is the richest single source for execution-stage detection — malware detonation, living-off-the-land binary abuse, credential dumping tools. It is nearly blind to what happens before a process touches a host (initial access via a phished credential, for instance) and to what happens on infrastructure it doesn't run on, which today means most SaaS and IaaS control planes.

Network telemetry

Network sensors see communication patterns: beaconing intervals, DNS tunneling signatures, unusual data volumes, lateral movement over SMB or RDP, TLS certificate anomalies even without decrypting payloads. This plane is essential for detecting command-and-control and exfiltration, and it is often the only plane that sees unmanaged or IoT devices that can't run an endpoint agent. It is blind to what's inside an encrypted session's application logic and to identity context — a network sensor sees an RDP connection, not whether the account making it should ever be doing so.

Identity telemetry

Identity providers, directory services, and privileged access management systems see authentication events, MFA challenges and bypasses, token issuance and refresh, conditional access policy evaluations, and privilege changes. This plane is where credential-based attacks — the majority of real-world breaches — first become visible: impossible travel, session token replay, service account abuse, OAuth consent-grant phishing. It cannot see what an attacker does once inside a session unless that activity crosses back into a system that logs identity context, which is why identity has to be fused with endpoint and cloud telemetry rather than analyzed alone. This is also why identity is frequently the connective tissue across an entire kill chain, a point worth dwelling on further below and covered in depth in Algomox's identity and privileged access guidance and the identity security product documentation.

Cloud telemetry

Cloud control-plane logs (CloudTrail-equivalent events, Kubernetes audit logs, SaaS admin activity logs) see infrastructure and configuration changes: IAM policy modifications, security group changes, new API key issuance, workload scaling events, storage bucket policy edits. This plane catches privilege escalation via misconfiguration and infrastructure-as-code abuse that never touches a traditional endpoint or network sensor at all — an attacker who compromises a CI/CD pipeline's cloud credentials and pivots entirely within the control plane can be completely invisible to endpoint and network telemetry.

The practical implication for measurement: any effectiveness test that exercises only one plane at a time will systematically overstate coverage, because most real intrusions traverse all four. A ransomware operator who phishes a credential (identity), authenticates from an unusual geography (identity), moves laterally over SMB (network), disables endpoint protection with a living-off-the-land binary (endpoint), and finally stages exfiltration through a misconfigured cloud storage bucket (cloud) leaves a four-plane trail. A platform, or a testing methodology, that only checks whether each individual event would have generated an alert in isolation misses the entire point of XDR: whether the sequence assembles into one incident with one confidence score, or whether it fragments into four unrelated low-priority alerts that four different analysts triage independently and close.

Correlation mechanics: how unified detection actually happens

The mechanism that turns four telemetry streams into one incident is entity resolution followed by sequence correlation, and it is worth understanding both in enough detail to interrogate a vendor's claims about it.

Entity resolution is the process of recognizing that "jdoe" in the identity provider, "10.14.22.6" in the network flow logs, "WKSTN-4471" in the endpoint telemetry, and "arn:aws:iam::...:user/jdoe" in the cloud audit log all refer to points on the same graph — the same human, the same session, the same lateral movement path. Without reliable entity resolution, correlation degenerates into time-window heuristics ("these two alerts happened within five minutes of each other"), which produce both false merges (unrelated events coincidentally close in time) and false splits (related events separated by normal processing delay). Robust entity resolution requires a maintained asset and identity graph — a system of record mapping hostnames to IPs to user sessions to cloud principals, refreshed continuously as DHCP leases change, as users authenticate to new devices, and as cloud roles are assumed and dropped. This graph is infrastructure, not a feature; it has to be built and maintained before any correlation logic runs on top of it.

Sequence correlation then operates on the resolved graph, looking for chains of events across planes that match known attack patterns or deviate from an established baseline. There are three broad mechanisms in production use, and they trade off differently:

• Deterministic correlation rules encode explicit sequences ("failed MFA challenge followed by successful legacy-auth login from a new ASN followed by a new OAuth application consent grant within 30 minutes"). These are precise, explainable to an auditor, and fast to tune, but they only catch patterns someone thought to write down, and attackers who know the rule set can operate just outside its boundaries.
• Statistical baselining models normal behavior per entity (a user's typical login times, source geographies, and resource access patterns; a host's typical process ancestry) and flags multi-sigma deviations across planes simultaneously. This catches novel attack patterns the rule author never anticipated, at the cost of requiring weeks of clean baseline data per entity and producing more false positives during the learning period or after legitimate behavior change (a user changing roles, a host being repurposed).
• Sequence and graph machine learning models trained on labeled attack chains (from red team exercises, honeypot captures, or threat intelligence-derived synthetic data) score partial sequences for likelihood of being part of a broader attack, allowing earlier-stage detection before the full kill chain completes. These require the most engineering investment and the most rigorous validation because their false positive and false negative behavior is the least intuitively predictable of the three.

Effective platforms run all three in combination, with deterministic rules handling the well-understood, high-confidence cases (a known ransomware note-drop pattern, for instance), statistical baselining catching account and host behavior drift, and ML sequence scoring surfacing novel multi-stage patterns for analyst review with an explicit confidence band rather than a binary alert. Algomox's approach within the AI-native platform stack layers these deliberately rather than treating correlation as a single monolithic engine, precisely because each mechanism has a different failure mode and measuring the composite without decomposing which mechanism caught what makes tuning impossible.

The metrics that actually matter

With the architecture and mechanism understood, the metrics stop being arbitrary and start mapping to specific pipeline stages. The following set, taken together, gives a defensible picture of effectiveness; no single metric from this list should be reported in isolation.

Detection-stage metrics

Mean time to detect (MTTD) should be measured from the earliest telemetry event that is part of the attack chain, not from when the platform first raised an alert — the gap between those two timestamps is itself a critical metric (call it detection latency) because it reveals how much of the delay is data pipeline lag versus analytic lag. Dwell time, the interval between initial compromise and detection (however detection eventually occurred, including via external notification), remains the industry's most brutal honesty check; if dwell time in your incident retrospectives is measured in weeks while your dashboard MTTD is measured in minutes, the dashboard is measuring a different, easier population of incidents than the ones that matter.

Detection coverage against a technique framework (typically MITRE ATT&CK) measures what fraction of relevant techniques for your threat model and industry vertical have a validated detection, not merely a theoretical rule that exists in a content library. Coverage should be reported per tactic (initial access, privilege escalation, lateral movement, exfiltration, and so on) because platforms are rarely uniformly strong; a platform can have excellent execution-stage coverage and near-zero collection or exfiltration-stage coverage, and an aggregate percentage hides that entirely.

Fidelity metrics

True positive rate and false positive rate need to be measured against a labeled corpus of both real incidents (from red team exercises and actual historical intrusions) and known-benign activity that resembles attack patterns (IT administration scripts, backup jobs, legitimate remote access), because a platform tuned only against attack samples with no benign-lookalike testing will show great lab numbers and terrible production noise. Alert-to-incident ratio — how many raw alerts the platform generates for every incident an analyst confirms as real — is the single best proxy for whether correlation is actually reducing noise or merely relocating it; a ratio improving from 200:1 to 20:1 after enabling cross-plane correlation is a directly attributable, defensible effectiveness gain.

Response-stage metrics

Mean time to respond (MTTR), split into mean time to triage (how long until an analyst makes a disposition decision) and mean time to contain (how long until the threat is actually neutralized), separates analyst and tooling efficiency from automation efficiency. Automated containment rate — what percentage of confirmed incidents were contained by orchestrated response actions without waiting on a human — is where the highest-leverage improvements typically live, and where AI-assisted alert triage has the most measurable impact, because triage time is usually the largest single component of total dwell time for detected-but-not-yet-contained incidents.

Program-level metrics

Analyst efficiency (incidents handled per analyst per shift, adjusted for severity) and escape rate (confirmed incidents discovered through means other than the XDR platform — user report, external notification, audit finding) round out the picture. Escape rate deserves particular attention: it is the metric most vendors will never volunteer and the one that most honestly answers "is this platform actually working," because every incident that reaches the organization through a side channel is a direct measurement of platform blindness.

*Targets vary substantially by industry, regulatory posture, and threat model; treat these as starting anchors for a baseline conversation, not universal SLAs.

Detection coverage testing: from tabletop to continuous validation

A coverage percentage is only as trustworthy as the testing method behind it, and there are three tiers of rigor worth distinguishing because organizations often believe they are doing the top tier when they are actually doing the bottom one.

The lowest tier is tabletop and paper mapping: a security engineer reviews the ATT&CK matrix, checks off techniques the vendor's documentation claims to cover, and calls it a coverage assessment. This is better than nothing but measures marketing claims, not production behavior; a rule can exist in a content library and still fail to fire because a required log source isn't actually being ingested at sufficient fidelity, or because the rule's logic assumes a Windows event schema your endpoint agent doesn't populate that way.

The middle tier is atomic testing — running individual, scoped technique emulations (tools like Atomic Red Team-style test suites) against real production or production-representative endpoints and confirming the expected alert actually fires, with the expected fields populated, within an expected latency window. This is table stakes for any organization claiming to measure XDR effectiveness and should run on a recurring schedule, not as a one-time exercise, because detection content silently regresses as agents update, logging configurations drift, and infrastructure changes.

The highest tier is continuous, chained breach-and-attack simulation and purple team exercises that execute multi-stage attack sequences spanning all four telemetry planes and measure whether the platform correlates them into a single incident narrative rather than N disconnected alerts. This is the only testing tier that actually validates the cross-plane correlation claim XDR is sold on, and it should be run against realistic attacker sequences relevant to your actual threat model (a financial services firm should be testing business email compromise and wire fraud chains; a manufacturer should be testing OT-adjacent lateral movement and ransomware staging) rather than a generic canned scenario library.

The operational discipline that separates organizations who actually improve from those who run one impressive purple team exercise a year and stop: every gap identified during testing needs a ticket, an owner, and a retest date, tracked in the same system used for vulnerability management. A coverage gap that is documented in a report and never retested is functionally identical to no test having been run at all, six months later, once agents and rule sets have drifted again.

Worked example: tracing a lateral movement chain across all four planes

Concrete example grounds all of the above. Consider a realistic intrusion sequence and what each telemetry plane sees, what a single-plane tool would report, and what a correctly functioning XDR correlation layer should produce instead.

1. Initial access (identity plane): An attacker uses a purchased credential to authenticate to a VPN concentrator from a residential proxy IP geographically inconsistent with the user's normal pattern. MFA is satisfied via a fatigue-based push-bombing attack. Identity telemetry shows: successful authentication, unusual source ASN, multiple MFA push rejections followed by one acceptance within 90 seconds — a classic push-bombing signature.
2. Discovery (endpoint plane): Once on the internal network via VPN, the attacker's session executes a handful of built-in reconnaissance commands (network share enumeration, local group membership queries) from a legitimate remote administration tool already present on the estate. Endpoint telemetry shows a normal-looking process, but the parent session correlates to the just-authenticated identity from step one.
3. Lateral movement (network plane): The attacker pivots to a domain controller-adjacent host using valid, harvested service account credentials over SMB, a protocol and account pairing that has never been observed together in the environment's baseline. Network telemetry flags the anomalous SMB session; in isolation this is a low-confidence anomaly because valid credentials were used.
4. Privilege escalation and staging (cloud plane): The compromised service account also holds a role in the cloud IAM system left over from a decommissioned integration. The attacker assumes that role and creates a new access key, then uses it to enumerate storage buckets. Cloud audit logs show a role assumption from an internal IP that has never assumed that role before, followed immediately by new access key creation — a strong privilege-escalation signature on its own.

Evaluated plane by plane, each individual event ranges from low to moderate confidence: push-bombing MFA acceptance is suspicious but not conclusive on its own (users do sometimes fat-finger accept legitimate pushes); the SMB session uses valid credentials; the cloud role assumption is unusual but not impossible for legitimate but poorly documented automation. A single-domain tool evaluating any one of these in isolation would, at best, generate a medium-severity alert that a triage analyst under alert-fatigue pressure could reasonably deprioritize.

Correctly performed cross-plane correlation changes the picture entirely: the same resolved identity entity connects all four events within a 40-minute window, and the sequence itself — anomalous authentication, immediate reconnaissance, credential reuse across a network hop that has never been observed for that account, followed by cloud privilege escalation from the same session — matches a known attack pattern with high confidence regardless of how unremarkable any single event looks alone. This is the concrete, falsifiable test of whether an XDR platform's correlation claim is real: feed it exactly this kind of chained, individually-subtle sequence and check whether it produces one high-confidence incident or four separate medium-confidence alerts assigned to whatever team happens to own each source system. Solutions oriented around agentic SOC operations are specifically designed to run this kind of cross-plane reasoning as a standing analytic rather than a one-off investigation an analyst has to manually assemble under time pressure.

Signal-to-noise: why triage automation is the real lever

Even a platform with excellent telemetry coverage and solid correlation logic will fail in practice if the resulting alert volume overwhelms the humans downstream of it. This is the single most common reason well-architected XDR deployments underperform their theoretical capability: the correlation layer works, but the investigation layer becomes the bottleneck, and burned-out analysts start pattern-matching on alert titles rather than reading the underlying evidence.

Measuring this requires tracking triage time distribution, not just the mean. A mean triage time of eight minutes sounds reasonable until the distribution reveals that ninety percent of alerts get a ninety-second glance-and-dismiss while the ten percent that are real incidents get starved of the deep investigation time they need because analysts are conditioned by the ninety percent to expect noise. This is where automated evidence assembly — pulling the relevant process tree, the authentication history, the network flow context, and the cloud audit trail into one pre-built narrative before a human ever opens the alert — produces measurable gains that are worth quantifying explicitly: track median time-to-first-meaningful-action separately for automation-assisted versus manually-assembled incidents over a rolling quarter, and the delta is a direct, defensible ROI number for any triage automation investment.

False positive reduction deserves the same rigor as detection improvement, and it is frequently under-invested because it doesn't show up as a shiny new detection capability in a vendor release note. A structured false-positive review process — sampling a fixed percentage of dismissed alerts weekly, confirming the dismissal was correct, and feeding confirmed false-positive patterns back into rule tuning or baseline retraining — is unglamorous operational discipline, but it is the single highest-leverage activity most SOCs can do to improve effective coverage, because analyst attention is the scarcest resource in the entire pipeline, scarcer than any telemetry source or licensing budget.

A buyer's framework: build, extend, or replace

For engineers and architects evaluating whether to build cross-domain correlation in-house, extend an existing SIEM with XDR-style analytics, or adopt a purpose-built XDR platform, the decision hinges less on feature checklists than on three structural questions.

Do you already have the entity resolution graph as durable infrastructure, or would you be building it from scratch? Organizations that have already invested in a mature configuration management database, an identity graph, and consistent asset tagging across cloud and on-prem estates have done the hardest, least glamorous part of the work already, and extending a SIEM with correlation logic on top of that foundation can be genuinely competitive with a commercial XDR platform. Organizations without that foundation will find that a commercial platform's biggest hidden value is the entity resolution engine itself, not the detection rule library, which is comparatively easy to replicate.

Can your team sustain continuous detection engineering, or does it need a vendor's content pipeline? Detection rules and ML models decay as attacker techniques evolve and as your own environment changes; a platform's ongoing content updates, informed by telemetry across its entire customer base rather than just your environment, is a meaningfully different capability than a static rule set your team wrote once and rarely revisits. Weigh this honestly against your team's actual bandwidth for detection engineering, not aspirational bandwidth.

What deployment constraints are non-negotiable? Air-gapped and sovereign environments — common in critical infrastructure, defense, and regulated government contexts — eliminate most cloud-native XDR vendors outright, because their correlation and ML components assume connectivity to a vendor-hosted backend. If your environment requires fully on-premises or air-gapped operation, this single constraint should be the first filter applied to any vendor shortlist, well before feature comparison, because retrofitting a cloud-first platform for air-gapped operation is rarely a clean exercise and often quietly degrades exactly the correlation and threat intelligence enrichment capabilities that justified the purchase in the first place.

A practical proof-of-value structure that surfaces real answers rather than sales-demo answers: run the vendor's platform against your own environment for a minimum of six weeks (shorter windows rarely capture enough baseline behavior for statistical detection to mature), inject the chained multi-plane attack sequence described earlier via a controlled red team exercise partway through, and measure the metrics table above — detection latency, ATT&CK coverage by tactic, alert-to-incident ratio, and automated containment rate — before and after the injected exercise, using your own analysts rather than vendor solution engineers running the triage. Insist on seeing raw telemetry ingestion volumes and gaps during the trial, not just the vendor's summary dashboard; telemetry that silently fails to ingest is the most common cause of a disappointing production rollout after an impressive proof-of-value.

Deployment models and their measurement implications

Where the platform runs changes what's measurable and how. Cloud-hosted SaaS XDR platforms typically offer the richest out-of-box analytics because the vendor can train correlation models across a broad customer telemetry base, but they introduce data residency and latency considerations that matter for regulated industries, and effectiveness metrics need to separately account for the telemetry forwarding latency between your environment and the vendor's backend, which can materially affect MTTD for genuinely time-sensitive detections like ransomware encryption onset.

On-premises deployments trade that cross-customer model training benefit for full data control and typically lower forwarding latency, but shift the burden of detection content maintenance more heavily onto the vendor's update mechanism or your own team, and effectiveness measurement needs to explicitly track how current the deployed rule and model set is relative to the vendor's latest release — a common and under-measured failure mode is an on-prem XDR deployment running detection content that is a year stale because update deployment was never operationalized as a routine.

Air-gapped and sovereign deployments, increasingly common for government, defense, and critical infrastructure operators, require the most deliberate measurement discipline because automatic threat intelligence feed updates and cloud-based model retraining are unavailable by design. Effectiveness in this context depends heavily on a well-defined manual content update cadence (how threat intelligence and detection rule updates get physically transferred into the environment, how often, and by whom) and on local, environment-specific baselining since the vendor cannot lean on cross-customer telemetry to tune statistical models. Organizations operating in this mode should track content freshness (days since last rule and intelligence update) as a first-class effectiveness metric alongside the detection metrics above, because a technically excellent correlation engine running six-month-old technique coverage against a threat landscape that has moved on is not actually effective, regardless of what its coverage percentage says on paper.

Across all three models, exposure management deserves to sit alongside detection metrics rather than in a separate program, because the two are complementary halves of the same risk picture: detection effectiveness tells you how well you catch an attack in progress, while continuous exposure and attack-surface visibility, covered in depth under continuous threat exposure management and exposure management practices, tells you how much attack surface exists for detection to even need to catch in the first place. A mature program reports both together: exposure reduction should show up as a declining rate of high-severity findings requiring detection reliance at all.

Reporting to leadership and closing the improvement loop

Metrics that live only in an analyst dashboard rarely drive budget or staffing decisions; effectiveness measurement needs a governance cadence that gets the right numbers in front of the people who can act on them. A practical structure: a weekly operational review inside the SOC covering alert-to-incident ratio, triage time distribution, and any detected coverage gaps from the current testing cycle; a monthly cross-functional review with IT operations and cloud engineering covering telemetry ingestion health and entity resolution graph completeness (since gaps here are frequently caused by infrastructure changes outside the security team's direct control); and a quarterly executive review covering dwell time trend, escape rate, ATT&CK coverage by tactic against the current threat model, and the results of the most recent chained breach-and-attack simulation.

The quarterly review is where the escape rate metric earns its keep: presenting leadership with "here are the incidents our tooling did not catch, and here is what we changed as a result" is a categorically more credible narrative than a dashboard trending uniformly upward, and it builds the kind of trust that survives the inevitable quarter where a real gap is found. Organizations that suppress or soften this number in executive reporting consistently find themselves under-resourced for the gaps that eventually surface anyway, at a worse time and with less goodwill.

Closing the loop operationally means every metric in this framework feeds a specific, owned action: a widening alert-to-incident ratio triggers a rule and baseline tuning sprint; a coverage gap in a specific ATT&CK tactic triggers either new telemetry onboarding or new correlation logic; a rising escape rate triggers a root-cause review of exactly which telemetry plane or entity resolution failure allowed the incident through undetected. Treat this as seriously as a vulnerability management SLA, with ticket ownership, remediation deadlines, and retest verification, and the metrics stop being a quarterly vanity report and start functioning as the actual control loop that improves the program month over month. For organizations building this discipline into a broader integrated operations model spanning both security and infrastructure teams, the same correlation and telemetry principles extend naturally into integrated NOC-SOC operations, where availability and security signals increasingly need the same kind of cross-domain entity resolution described throughout this piece, and further detail on the broader AI-driven security posture is available through Algomox's AI security resources and the technical whitepaper library.

Frequently asked questions