DE.AE-04 impact and scope estimation: what the requirement asks for
When an alert or finding lands, the first questions are how bad it is and how far it reaches. DE.AE-04 asks that the estimated impact and scope of adverse events are understood. It sits in the Adverse Event Analysis Category of the Detect Function in NIST CSF 2.0, and it continues CSF 1.1 DE.AE-4 at the same identifier, so teams with an existing 1.1 program can carry their work forward without renumbering. The requirement does not prescribe a method. An estimate can come from a tool, such as a SIEM correlating several log sources against asset and user context, or from an analyst who weighs what is known about the systems, data and accounts involved. NIST's Implementation Examples describe both approaches and a third step that matters as much as the first two: refining the estimate as the investigation produces facts.
The risk is sizing the event wrongly in either direction. An event judged too severe pulls responders into containment, executive notification and customer communication that the facts do not support. An event judged too small leaves lateral movement, a second compromised host or a exposed data store unexamined while the first alert is closed. Three conditions make this hard in practice. Severity scores mean different things to different analysts, so two people reading the same alert reach different answers. Asset inventories and data classifications are missing or stale, so the estimate cannot tell a test workstation from a domain controller. And estimates are written once in the ticket and never revisited, even after the investigation has changed the picture.
To act on this, confirm three things in your own environment. First, that the scoring criteria for impact and scope are written down and applied the same way across shifts, with a named owner for changes. Second, that your SIEM or detection platform can pull asset criticality and owner data into an alert, and that the people who triage alerts know where that data comes from. Open-source options such as OpenSearch Security Analytics, which records matches as findings with rule, log type and severity and links related findings through a correlation graph, or Wazuh, which maps alerts to MITRE ATT&CK, can supply the raw signals, but they do not judge business impact on their own. Third, that each incident record shows the estimate, the date it was last revised and the evidence behind the change. Confirm the exact wording of the subcategory and its Implementation Examples in the NIST CSF 2.0 publication before you map your procedures to it.
Which systems, teams and data DE.AE-04 covers in practice
An impact and scope estimate is only as complete as the boundary drawn around it. The cards below cover the decisions that set that boundary: which log sources feed the estimate, which classifications it relies on, who makes and approves it, and which third parties hold relevant data. Settle these choices before an assessor asks for evidence, because each one changes what the estimate must cover.
Log sources and detection tools
Decide which hosts, network devices, identity systems and cloud services feed the detection tools whose output informs the estimate. An estimate built only from endpoint alerts can miss scope in identity or cloud logs. In an open-source stack such as OpenSearch Security Analytics or Wazuh, check which log types are ingested, which detectors are enabled, and whether gaps in collection are recorded anywhere an analyst would see them before estimating impact.
Asset and data classifications
Impact estimates depend on knowing which assets and data sets matter most. Confirm that the organization has an asset inventory with owners and a data classification scheme that analysts can query during an event. Without these, an estimate can state that ten hosts were affected but not whether any of them hold regulated or business-critical data. Record which classification source is authoritative and who maintains it.
SOC and incident roles
Name who prepares the first estimate, who refines it as facts change, and who approves the figure that goes into an incident record or a notification decision. Analysts may make the initial call, while incident commanders, legal counsel or privacy officers often confirm scope where contractual or regulatory duties depend on it. Write these roles into the response plan so an assessor can see a named approver for each estimate.
Third-party services holding data
A managed SOC, a managed detection provider or a cloud log service may store or process logs that are needed to judge scope. Confirm where those logs reside, how long the provider keeps them, and how quickly you can obtain them during an event. Contracts should state the provider's duty to supply the records needed for impact estimation, so the estimate does not stall while a third party is asked for data.
Refinement and re-estimation triggers
Decide what new facts cause an estimate to be revisited, such as additional affected hosts, confirmed data access or a change in attacker dwell time. Define how often the estimate is reviewed during an active event and where each revision is recorded. An estimate that is never updated after its first version is hard to defend, because the subcategory expects estimates to be refined as understanding improves.
How an assessor tests impact and scope estimation
This table compares what an assessor does, what evidence they request and the findings they commonly raise for DE.AE-04. Assessors sample adverse events rather than review every estimate, so each sampled event needs its own traceable estimate. The main takeaway is that a stated basis, a refinement record and a consistent severity scale matter as much as the estimate itself.
| Assessment step | What the assessor does or requests | Common finding when it fails |
|---|---|---|
| Sample recent adverse events | Selects a sample of recent events from the detection platform or ticketing system and asks for the impact and scope estimate recorded for each. | The organization cannot produce an estimate for one or more sampled events, or the estimate exists only in an analyst's memory. |
| Trace the estimate and its inputs | Follows each estimate back to its inputs, such as affected hosts, accounts, data types, log sources and SIEM correlation results, and checks that the inputs match the event record. | Estimates with no stated basis, where the assessor cannot tell which assets, users or systems were considered. |
| Check the tooling configuration | Reviews the detector, rule or correlation configuration that produced or supported the estimate, including the rule version in effect on the event date. | Rule or detector changes made without a record, so the estimate cannot be tied to the logic that existed when it was made. |
| Check refinement after new facts | Looks for later updates to the estimate when new information arrived, such as additional affected systems or confirmed data exposure, and confirms each update has a timestamp and author. | No refinement record, or estimates that stay unchanged after the investigation showed a larger or smaller scope. |
| Check severity consistency | Compares how impact and scope are rated across analysts, teams and event types to confirm one scale is applied and documented. | Inconsistent severity scales, where the same kind of event is rated high by one analyst and low by another with no documented reason. |
| Review analyst judgment | Where an analyst made the estimate without tool support, asks for the notes showing the reasoning and the sources consulted. | Analyst notes that record a conclusion without the reasoning or the evidence behind it. |
| Review change history | Asks for the audit trail of edits to estimates, scoring criteria and detection rules over the review period. | Overwritten records with no history, so the assessor cannot see how an estimate changed over time. |
| Confirm the organization owns the result | Confirms that the organization, not the implementation partner, produced and approved the estimates and the procedures behind them. | Estimates prepared by an outside party with no internal review or sign-off recorded. |
Implementing DE.AE-04 step by step
This sequence turns the DE.AE-04 outcome, an understood estimate of the impact and scope of adverse events, into written criteria, detection coverage, an estimation procedure and a tested record of how estimates are made and refined.
Define impact and scope criteria
The security lead, with business owners of the systems in scope, writes down what impact and scope mean for the organization. Criteria typically cover which systems, data types, customers and business processes are affected, and how severity levels map to them. Agree the wording with the incident response lead so that estimates use the same vocabulary as declaration and recovery. The output is a criteria document with named owners and a version date. The step is done when every severity level has a description a second analyst would apply the same way.
Map log sources and detectors to criteria
The detection engineering team lists the log sources that can show scope, such as identity systems, endpoint telemetry, network logs and cloud audit trails, and checks which detectors or SIEM rules produce evidence for each criterion. Where a criterion has no source or detector, record the gap as a finding. Tools such as OpenSearch Security Analytics or Wazuh can host these detectors, but confirm each rule's coverage in your own environment rather than assuming it. The output is a detection mapping that links each criterion to sources, detectors and known blind spots. The step is done when every criterion has at least one source or a documented gap.
Decide manual and automated estimation
The SOC manager and senior analysts define which estimates tools can produce, such as counting affected hosts or accounts from correlated alerts, and which need analyst judgment, such as business impact or likely data exposure. Set the rule for handing an estimate from automation to a person, including who may override a tool-generated scope. The output is an estimation procedure with clear steps, roles and the evidence each estimate must cite. The step is done when an analyst can follow the procedure for a new event without asking who decides.
Set refinement triggers and record format
The SOC lead defines the events that require an estimate to be revisited, such as new affected assets, new log evidence, a change in data classification or a handoff to incident response. Design a record template that captures the estimate, its evidence, its confidence, the analyst, the time of each revision and the reason for the change. Store records where the incident team and auditors can retrieve them. The output is a record template and a written refinement trigger list. The step is done when a revised estimate can be traced to its earlier version and its reason.
Test the process on past events
The SOC team selects a set of past adverse events of varied type and severity, applies the criteria, mapping and procedure to them, and compares the results with the scope established at the time. Record differences, unclear criteria and missing evidence in a test log, then revise the criteria or mapping and repeat the test on the changed items. Have someone who did not write the procedure run at least part of the test. The output is a test log with dated results and corrective actions. The step is done when the revised process produces estimates the reviewers accept and every open gap has an owner.
How OpenSearch and Wazuh can produce DE.AE-04 evidence
OpenSearch Security Analytics is a detection component of the OpenSearch project, licensed under Apache-2.0. Its detectors read logs that have been ingested from hosts, network devices and cloud services, then compare them against prepackaged or custom Sigma rules. Each match is recorded as a finding that carries the rule, the log type and a severity value, so a team can see which events were flagged, where they came from and how serious the rule considers them. For DE.AE-04, those findings are the raw inputs to an impact and scope estimate: they show how many sources a pattern touched and how severe the rule judged it to be. The correlation engine then links findings across log types in a correlation graph, which helps an analyst see whether one event is isolated or part of a wider set of affected systems.
- Detector findings: Each finding stores the matched rule, log type and severity, giving a dated record of what the detector saw.
- Alert channels: Alerts are sent to channels such as Slack or email, which creates a notification trail showing when the team was told.
- Correlation graph: Linked findings across log types help establish the number of hosts, accounts or services a single adverse event reached.
- Custom Sigma rules: Rules written for the organization's own assets let the scope reflect systems that matter to the business, not only generic signatures.
- Limits of the output: A severity label is a rule setting, not an estimate of business impact, so the analyst must record how the label was adjusted or accepted.
Confirm with your own deployment which log sources are ingested, which Sigma rules are enabled, and how findings are retained, because the evidence is only as complete as the data behind it.
Wazuh is an open-source security platform licensed under GPL-2.0-only. Its agents and manager collect events, and the decoder stage breaks each log into fields. The engine then compares each event against a ruleset of over 3,000 built-in rules and decoders, plus any custom rules the organization writes. Matching events are written to alerts.log and alerts.json, mapped to MITRE ATT&CK techniques where the rule supports it, and forwarded to the Wazuh indexer for review in the dashboard. For DE.AE-04, these alert files give a durable, machine-readable record of which hosts generated which rule matches over a period, which is the starting point for estimating how far an event has spread. The MITRE mapping also helps the analyst describe the likely attacker activity, which informs the impact judgment.
- Decoded events: Field-level decoding makes it possible to count affected agents, users or hosts from the same alert format each time.
- Alert files: alerts.log and alerts.json preserve matches in files that can be exported to the case record or retained for an assessor.
- MITRE ATT&CK mapping: Technique tags indicate the kind of activity seen, which supports a documented reasoning step for impact.
- Custom rules: Organization-specific rules can flag activity on critical assets, so the scope reflects the systems that carry the most risk.
- Indexer and dashboard: Forwarded alerts can be filtered by agent group and time window, which helps refine an estimate as new events arrive.
Confirm the agent coverage, rule versions and retention period in your environment, since scope estimates are only defensible for the systems and periods that actually reported.
Neither platform produces the DE.AE-04 outcome by itself. The Subcategory is about the estimated impact and scope being understood, and the NIST Implementation Examples describe either using tools to estimate and refine, or having a person make their own estimates. In practice, both tools feed the analyst with severity, affected sources and linked findings, while the organization decides what those facts mean for its business. An assessor will want to see a written estimate, the data it relied on, who made it, what assumptions it used and how it changed as more evidence arrived. The platforms can supply most of the data for that record, but the record itself is a procedure the organization must run and keep.
- Estimate record: A ticket or case note should state the estimated impact, the scope in hosts, accounts or services, and the time window.
- Source references: The record should cite the OpenSearch finding IDs or Wazuh alert entries used, so the reasoning can be traced.
- Refinement log: Each change to the estimate should be dated and explained, showing that estimates are revisited.
- Analyst sign-off: A named role should confirm the estimate, which shows human judgment rather than default tool output.
- Licensing check: Apache-2.0 and GPL-2.0-only terms should be reviewed against how the platform is distributed, modified and used internally, and the legal or open-source review owner should confirm the fit.
Ask your team to show one closed adverse event with its estimate record, the tool evidence behind it and the refinement history, because that single example is what an assessor will test first.
Evidence that passes DE.AE-04 and how to keep it current
An assessor testing DE.AE-04 will look for a chain of records: criteria that define impact, estimates made for each event, proof that estimates changed when facts changed, and detection configuration that matches what the organization says it does. The cards below list each artifact, how often it should be refreshed between audits, and who owns it. Refresh intervals are a starting point to agree with your auditor and internal governance, not a fixed requirement.
Written impact and scope criteria
A dated document that defines how the organization rates impact (for example, data classes affected, number of customers, service availability and regulatory exposure) and how it bounds scope (which systems, accounts, identities and data stores count as in scope). Without written criteria, analysts cannot show consistent estimates. Check that the criteria reference the asset inventory and the business services they protect. Refresh it at least after each significant incident and after material changes to systems or data flows. Owner: the head of security operations, approved by the risk committee.
Estimate records for each event
One record per adverse event showing the estimated impact and scope, the inputs used (log sources, affected hosts, accounts and data types), the basis for each judgment, and the time the estimate was made. Assessors sample these records to confirm estimates exist for events, not only for incidents already declared. Check that each record names the analyst or tool that produced it. Review sampled records during internal quality checks each quarter. Owner: the SOC lead, with analysts as record authors.
Refinement history after new facts
A log of how estimates changed as investigation progressed, such as a wider scope after lateral movement appeared in logs or a narrower one after a host was confirmed clean. The DE.AE-04 Implementation Examples describe refining estimates, so this history is the direct evidence of it. Each entry should state what new fact triggered the change and who approved it. Keep the history attached to the event record so it cannot be edited separately. Owner: the incident handler on shift, reviewed by the SOC lead.
Detector and rule configuration history
Exports of the SIEM or detection platform settings that produce impact and scope inputs, including detectors, Sigma or custom rules, log sources and alert channels, held under version control with change approvals. Where a tool such as OpenSearch Security Analytics or Wazuh supplies findings, the assessor will want to see which rules were active on the date an estimate was made. Confirm the platform's own export and audit logging options before relying on them. Review configuration changes monthly and record each approved change. Owner: the detection engineering lead.
Analyst judgment notes
Written notes where a person estimated impact without a tool, or overrode a tool's estimate. These show reasoning on events that automation could not size, which the second DE.AE-04 Implementation Example covers. Samples should show the facts considered, the uncertainty acknowledged and any follow-up requested. Review a sample of notes each quarter to check that judgments are consistent across analysts and shifts. Owner: each analyst for their notes, with the SOC lead responsible for sampling and calibration.
Link from estimates to incident declaration
Evidence that estimates feed the decision to declare an incident, including the threshold that moves an event to DE.AE-08 and the records showing when that threshold was met. Assessors check whether estimates were considered in declaration decisions and whether declined declarations were justified. Test the link with a tabletop exercise or a sampled event each year. Owner: the incident response manager, with the CISO accountable for the threshold.
What meeting DE.AE-04 costs in money and effort
This table lists the cost components of estimating impact and scope for adverse events, who is paid for each, whether it is one-time or recurring, and what moves it up or down. Use it to structure a request for a written scope, since no prices or durations are published for this work.
| Cost component | Who is paid or who spends effort | One-time or recurring | What drives it up or down | What to ask for in a written quote |
|---|---|---|---|---|
| Tooling and licenses | Software vendor for commercial SIEM or detection products; no license fee for open-source platforms such as OpenSearch Security Analytics or Wazuh | Commercial licenses are usually recurring; open-source tools carry no license fee | Log volume, number of log sources and retention period; open-source tools still need hosting, storage and patching | Line-item list of licenses, hosting and storage assumptions, and the basis for any per-volume charges |
| Engineering time to tune detectors and build estimate templates | Implementation partner or internal platform engineers | One-time, with periodic retuning | Number of log types and sources, quality of asset inventory, and how many detectors must be customized | Named deliverables for detector tuning, the number of estimate templates, and the acceptance criteria for each |
| Analyst time for estimates and refinement | Internal SOC or incident response analysts | Recurring, scaling with event volume | Event volume, staff skills in scoping, and how often estimates are revised as new data arrives | Expected analyst roles and time allocation for the engagement, and how refinement is documented |
| Evidence upkeep | Internal compliance staff or the implementation partner preparing records | Recurring, usually tied to assessment cycles | How many estimates must be retained, how they are linked to tickets, and the format assessors expect | Evidence list by assessment cycle, storage location and who maintains it |
| External review or testing | Independent security testing firm or internal assessor | Usually periodic, tied to a test or review cycle | Scope of detection coverage tested, whether AI-assisted or cloud components are included, and test depth | Testing scope, methods, rules of engagement, and deliverable format |
| Auditor sampling effort | Independent auditor or certification body (fees set by the auditor, not by DeployOpen) | Recurring, per assessment cycle | Number of samples the auditor selects, quality of records, and whether estimates are traceable to events | Auditor fee basis and sampling approach, confirmed directly with the auditor |
| Training for analysts | Training provider or internal trainers | One-time for onboarding, recurring for refresher training | Staff turnover, tool changes and the skill gap in impact estimation | Course content, duration, and whether the training covers the tools deployed |
Who owns DE.AE-04, who helps, and where the auditor stops
Your organization owns DE.AE-04. NIST describes the outcome as understanding the estimated impact and scope of adverse events, and that understanding has to live with the people who handle incidents and answer for the decisions. Analysts and incident leads make the judgment calls about how far an event reaches, which systems, accounts and data are affected, and when an estimate is revised. The procedure that governs those calls, and the records that show them, also stay with you.
- Estimation procedure: Define how analysts estimate impact and scope, which inputs they use (asset inventory, log correlation, business criticality) and when they must refine an estimate.
- Analyst decisions: Record who made each estimate, the reasoning, and what changed when new evidence arrived.
- Event records: Keep the tickets, timelines and tool findings that show the estimate was made and updated during the event.
- Escalation thresholds: Decide which estimates trigger leadership notice or the handoff to incident response.
- Tool ownership: Keep accountable administrators for any SIEM or detection platform that produces the data behind estimates.
Before relying on this tab, check that someone on your staff can explain a past estimate from the records alone.
An implementation partner such as DeployOpen can plan and configure the detection tooling that supplies estimation data, prepare the written estimation procedure for your review, and set up the places where records and evidence are kept. Partners can also run test cases to confirm the process works as written. What a partner does not do is decide the impact of a real event or issue any assessment result. Those remain with your team and with an independent assessor respectively.
- Tool configuration: Set up log sources and detection rules so estimates draw on complete, timestamped data.
- Procedure drafting: Prepare estimation steps and templates that your analysts review and approve.
- Evidence preparation: Organize event records, ticket fields and tool exports so an assessor can sample them.
- Test runs: Execute simulated events to confirm estimates are recorded and refined as the procedure requires.
- Documentation: Write the configuration and runbook material your staff keeps after the engagement ends.
In scope, the work is agreed in writing before it starts, so confirm that each item above appears in the statement of work.
An independent auditor, assessor or certification body is the only party that tests whether DE.AE-04 is met and issues any report or conclusion. NIST states that it does not certify or endorse CSF implementations or services and has no conformity assessment program, so no NIST body can confirm that your estimates are adequate. Assessors typically sample past adverse events, compare the estimates against the records, and check whether refinements happened when the evidence changed. Their conclusions depend on the evidence you provide, so the independence of their work is what gives it weight.
- Sample selection: The assessor chooses events, and you do not choose which ones they test.
- Record testing: They compare estimates against timestamps, tool findings and analyst notes.
- Refinement checks: They look for evidence that estimates were revisited as new information arrived.
- Reporting: Only the assessor issues the findings or report that a customer or regulator may rely on.
- Scope agreement: Confirm with the assessor which framework version, profile and organizational scope they will test.
Ask any assessor you engage to confirm in writing which artifacts they will request and how they handle sampling.
Where organizations fall short on impact and scope estimates
Most impact and scope problems are not about missing tools. They come from estimates that are undocumented, unanchored to what the business values, inconsistent between people, and never revisited. The cards below describe each gap and the action that closes it, so an assessor can trace a sizing decision from alert to outcome.
Estimates live in chat threads
An analyst says an event touched three hosts and a finance share, the thread moves on, and nothing is recorded in the ticket. DE.AE-04 expects the estimated impact and scope to be understood, which an assessor can only confirm when the estimate, its date and its author are kept with the event. Check a sample of closed detections and confirm each one carries a written scope statement. Make a required scope field part of the ticket template so the estimate cannot be skipped.
No link to asset criticality
An estimate that counts affected systems but ignores what those systems do is not an impact estimate. A workstation and a payment switch can both generate the same alert while carrying very different consequences. Tie each estimate to an asset inventory field for business criticality and a data classification label, and confirm that the inventory is current enough to support the lookup. Without that link, the estimate cannot be defended to an auditor.
Severity scales differ between analysts
One analyst reads medium as a day's delay, another reads it as an executive escalation. When the scale is not defined, two identical events produce two different impact statements, and the SOC cannot compare trends. Write a short impact scale with concrete criteria for each level, such as affected data types, number of users and service dependencies, then calibrate it by having two analysts score the same sample events and reconciling the differences.
Estimates are never refined
The first estimate is often made within minutes of an alert, before logs are correlated or the attacker's path is known. DE.AE-04 covers refining the estimate as facts arrive, and many teams never do it. Set a rule that the responder updates the impact and scope fields at defined points, such as after correlation, after containment and at closure, and keep each version rather than overwriting it so the change history shows the reasoning.
Alerts are never sized
A SIEM or detection platform can generate thousands of findings, and a large share may never receive an impact or scope value. Detection rules that fire without sizing create a backlog that looks like coverage on paper. Review the findings queue each week, count those with no impact value, and set the tool to require a severity or asset tag before a finding can be closed. Confirm the field names and workflow options in your own deployment, since they vary by platform and version.
The process is never tested
A written procedure proves little if no one has ever run it against a realistic event. An assessor will look for evidence that estimates were produced, reviewed and corrected in practice, such as tabletop exercise records or retrospective reviews of past incidents. Run a scheduled exercise that injects a known event, then compare the estimate produced against the answer. Record the gaps and feed them back into the scale and the ticket template.
Questions buyers ask about DE.AE-04 cost, effort and outsourcing
How much effort does DE.AE-04 take to meet?
Effort depends mostly on how many log sources feed your detection tooling, how complete your asset inventory is, and how many analysts must review and refine estimates. DE.AE-04 asks that the estimated impact and scope of adverse events be understood. NIST describes two ways to do this: use a SIEM or other tools to estimate impact and scope and refine those estimates, or have a person make their own estimates. Most organizations use both, so the work is partly technical (building enrichment, asset tagging and dashboards) and partly procedural (defining how analysts record and revise estimates). Ask any partner to split the effort into these two parts so you can see where the hours go.
Can we meet DE.AE-04 in-house with open-source tools?
Yes, many teams do, provided they have staff who can operate the tooling and make judgment calls on impact. Open-source options such as OpenSearch Security Analytics and Wazuh can ingest logs, match them against detection rules, record findings with severity, and group related events. OpenSearch Security Analytics uses a correlation engine to link findings across log types, and Wazuh maps alerts to MITRE ATT&CK. These tools produce the raw material for impact estimates, but they do not decide impact on their own. Confirm with each project's documentation which features your version includes, and confirm that your analysts can record how and why an estimate changed over time.
How long does DE.AE-04 readiness work take?
No duration is supplied for this work, and it depends on scope. The main variables are the number of systems in scope, whether logs are already centralized, the maturity of your asset inventory, and whether impact criteria already exist in your incident procedures. An organization with centralized logs and documented criteria has a shorter path than one starting from scattered logs and no classification of business services. Ask for a written timeline tied to specific deliverables, such as a defined estimation method, a working detector set and a reviewed procedure, rather than a single calendar figure.
What does DE.AE-04 need from our team before work starts?
The work needs three inputs from your side: access to relevant logs, reliable asset data, and analyst time. Log access means read access to the sources that show activity on systems and identities that matter for impact, such as endpoints, identity providers, network devices and cloud audit logs. Asset data tells the estimate which systems support which business services and how sensitive their data is. Analyst time covers workshops to define impact levels, review of sample alerts, and sign-off on the estimation procedure. Confirm who in your organization owns each input before the engagement begins, because delays usually come from these three items.
Can a partner certify that we comply with DE.AE-04?
No. NIST does not offer certifications or endorsements of CSF-related products, implementations or services, and it has no plans for a conformity assessment program. Under NIST's approach, your organization owns its controls and reports its own alignment. A partner such as DeployOpen can plan, implement and document the detection and estimation capability and prepare the evidence. Only an independent assessor or auditor, which you engage separately, can issue conclusions about whether the outcome is met. Be cautious of any offer that promises a NIST certificate for this outcome.
What should a fixed-scope quote for DE.AE-04 include?
A fixed-scope quote should list the deliverables, the systems and log sources covered, the tooling to be deployed or configured, and the testing or review steps. Ask for the following in writing:
- The log sources and asset groups included, and those excluded
- The estimation method, including who approves impact levels
- The detector and rule set to be configured, with the version of each platform
- The evidence the engagement will produce, such as configuration records and sample estimates
- The client inputs required and the dates by which they are due
- Which items are one-time work and which recur, such as rule tuning or support retainers
- How changes to scope are priced and approved
A quote built on these items lets you compare proposals on the same basis.
Which parts of DE.AE-04 are usually outsourced?
Organizations commonly outsource the platform build, detector configuration, integration with log sources and documentation, because these tasks need specialized engineering time. They usually keep ownership of impact criteria, the business mapping of services, and final sign-off on estimates, since those decisions depend on risk appetite and internal knowledge. Ongoing rule tuning and upgrades can be contracted as a retainer after the initial build. Decide the split before work starts, and record it in the statement of work so that responsibilities for each estimate are clear.
How DeployOpen works on this
DeployOpen scopes DE.AE-04 Impact and scope estimation as a fixed-scope engagement, then prepares the detection tooling, procedures and records your organization needs to show how it estimates the impact and scope of adverse events. DeployOpen prepares the systems and evidence, while your organization owns the control and an independent auditor or assessor issues any report.
How we scope
- Agree in writing which log sources, SIEM or detection tools, and event types are in scope for impact estimation.
- Confirm which teams, roles and analyst decisions estimate impact and scope, and where each estimate is recorded.
- Define how estimates are refined as new findings arrive, so the scope document matches your actual triage process.
How we build
- Configure detection and analysis tooling, such as OpenSearch Security Analytics or Wazuh, to tag findings with severity and affected assets.
- Build the procedure for analyst judgment, including the fields needed to record affected systems, data and users for each event.
- Test the workflow with sample events so that estimates can be traced from first alert through each refinement step.
How we hand over
- Deliver written procedures, configuration records and a mapping of the workflow to DE.AE-04 and its Implementation Examples.
- Export sample findings, alert records and estimate revisions so your assessor can trace each step to evidence.
- Walk your security operations and compliance staff through the evidence set, and note open items for your own owners to close.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer, agreed in writing after the initial scope.
- Review estimate records and detection rules after tooling upgrades or changes in your environment.
- Confirm with your auditor or assessor which evidence formats and sampling they expect before the assessment begins.
