What DE.AE-07 threat intelligence requires in analysis
DE.AE-07 asks that threat intelligence, asset inventory data and vulnerability disclosures are built into how adverse events are analyzed. It sits in the Detect Function of the CSF 2.0 Core, within the Adverse Event Analysis (DE.AE) Category, which covers how an organization makes sense of events it has already detected. The Detect Function is about finding possible attacks in time to act, and DE.AE is the step where raw alerts are judged. The Subcategory describes an outcome, not a product. NIST does not require a particular feed, platform or threat intelligence program. What the reader must show is that an analyst who looks at an alert can see who is targeting similar environments, which assets the alert touches, and whether a known weakness on those assets is being exploited.
Analysts without that context tend to misjudge alerts in two directions. A benign administrative action on a server that is internet-facing and unpatched may be dismissed as routine, while a noisy scanner hit against a lab host may consume a shift. The hard part is that the inputs are rarely clean. Threat feeds can be noisy, duplicating commodity indicators that never match anything local, stale, with indicators that expired months ago, or unowned, with no one accountable for deciding which feeds are trusted. Asset inventories are often incomplete, missing cloud workloads, shadow deployments and third-party hosted services, so the match between an alert and a business owner fails silently.
A practical first check is to ask who owns each intelligence source, how often it is reviewed for relevance, and whether analysts can tie an indicator to a named asset within minutes. Confirm with your own team which inventory is authoritative for detection and which vulnerability disclosures reach analysts from suppliers and advisories. Where these answers are unclear, the gap is the finding to plan for. Auditors will look for evidence of the flow, not just a subscription list, so document the sources, the owners and the examples where context changed a decision.
Which feeds, inventories and teams fall inside DE.AE-07 scope
DE.AE-07 reaches further than a threat feed subscription. The work covers every source of intelligence, inventory and vulnerability information that changes how an event is analyzed, plus the people and third parties who act on the result. The cards below mark the inputs and roles to define before you estimate effort.
External threat intelligence sources
Commercial feeds, sector sharing groups, government advisories and open feeds all supply indicators and context. Each source has its own format, licensing terms and freshness, so the analysis depends on which ones you ingest and how often. Confirm which feeds are contractually allowed to be shared with an MSSP or a partner, and record who reviews a feed when its quality drops. Decide the source list before tooling, because every added feed adds normalization and false-positive tuning work.
Internal incident and case data
Your own past incidents, closed investigations and known false positives are often the most useful context for new alerts. Scope decides whether this history is fed back into correlation or kept only in the ticketing system. Check retention limits, whether personal data appears in case notes, and who may read them. Analysts tend to lose the most time when prior investigations exist but cannot be searched alongside current events.
Asset inventory systems
DE.AE-07 expects asset inventory information to reach detection, so analysts can tell whether an indicator touches a production host, a test system or a device nobody owns. Identify the authoritative inventory, such as a CMDB, cloud asset registry or endpoint manager, and the fields it reliably holds, including owner, criticality and exposure. Stale inventories are a common cause of unanswered questions during triage. Ask which teams keep the data current and how often it is reconciled.
Vulnerability disclosure channels
Supplier bulletins, vendor advisories and third-party advisories tell you which vulnerabilities could turn an observed event into a serious one. Inventory the channels for every product in use, including open-source components and managed services, and assign who triages each one. Rapid analysis depends on matching a disclosure to affected assets quickly, so the scope should name the software inventory source used for that match. Confirm how advisories reach the team after hours.
SOC and detection engineering teams
The SOC triages alerts, while detection engineers write and tune the rules that carry intelligence into detection. Scope should name who owns each indicator type, who approves a new rule and who retires an indicator that no longer applies. Splitting these duties across teams without a written handoff is a frequent source of gaps. Name one accountable owner for intelligence quality, even when several teams contribute.
MSSPs and third parties that analyze events
When an MSSP or other third party analyzes your events, the intelligence and inventory data they receive becomes part of your DE.AE-07 scope. NIST's small business guidance cites sharing incident details with an authorized responder such as an MSSP, which shows why the handoff belongs in scope. Confirm what data leaves your environment, how it is protected, where it is stored and whether the provider can see your inventory. The contract should match the data flows you document.
How an assessor tests DE.AE-07 threat intelligence
This table compares what an assessor does for each part of DE.AE-07, what evidence they ask the organization to produce, and where programs most often fall short. Read each row as a test the organization should be able to pass before an assessment begins. The main takeaway is that an assessor looks for a documented link from a feed to a detection and then to a decision, not for a list of subscriptions.
| Test area | Test approach and evidence requested | Common findings |
|---|---|---|
| Intelligence sources defined and reviewed | Assessor requests the register of threat intelligence sources, with the purpose, owner and review date for each. They sample feeds and check that the register matches what is actually ingested. | Feeds with no named owner, sources added during an incident and never recorded, and no review since onboarding. |
| Indicators reach detection technologies | Assessor traces a sample indicator from the feed into the SIEM, IDS or EDR rule set, and asks for the import log, sync schedule and rule that uses it. | Indicators stored in a platform but never exported to detection tools, or exports that fail silently for weeks. |
| Intelligence reaches people who act on it | Assessor checks that analysts and the SOC receive relevant intelligence through alerts, briefings or shared case context, and asks for the distribution list or sharing group settings. | Intelligence shared with one team only, or sent to a mailbox that nobody monitors. |
| Asset inventory available during triage | Assessor asks analysts to look up the owner, business role and exposure of an affected host during a sample triage. They compare the answer with the inventory of record. | Inventories that do not match live systems, missing cloud or SaaS assets, and no owner field for most hosts. |
| Vulnerability disclosures analyzed quickly | Assessor selects recent vendor or advisory disclosures and asks for the analysis record, the date received, the affected assets identified and the decision taken. | Advisories received by email and filed without analysis, with no record of which assets were checked. |
| Disclosures linked to affected assets | Assessor requires a traceable link between a disclosure, the matching inventory entries and any resulting tickets or patch records. | Tickets raised with no reference to the advisory, or links that point to assets retired months earlier. |
| Intelligence used in documented cases | Assessor reviews a sample of closed alerts and incident records and checks whether intelligence was referenced, applied or explicitly ruled out. | Intelligence collected for months but never cited in a documented case, which suggests it adds little to analysis. |
| Ongoing improvement | Assessor asks for review minutes or metrics showing that false positives, stale indicators and missing assets were corrected. | Reviews that happen on paper only, with no changes recorded to sources or rules. |
How to implement DE.AE-07 in a detection program
This sequence turns threat intelligence, asset context and vendor vulnerability disclosures into inputs that analysts can use when they examine a potential adverse event. Each step leaves a record your team can show an assessor. The organization makes every decision about sources, priorities and actions.
Define intelligence sources and their purpose
Start by listing each intelligence source you will rely on, such as commercial feeds, sector sharing groups, government advisories, or information from your MSSP. For each one, write down what it is for, such as detecting known infrastructure, prioritizing vulnerabilities, or supporting case analysis. Assign an owner who decides what is accepted and who reviews the source list on a schedule you set. Output: an approved intelligence source register that records purpose, owner, handling rules and any sharing restrictions.
Connect the asset inventory to detection context
Make sure the asset inventory covers hosts, software, cloud services and data flows that detections depend on, and that each asset has an owner and a criticality value. Load this data into the detection platform or SIEM as enrichment so that an alert shows which system is involved and how important it is. Confirm the match keys (hostnames, IP ranges, asset IDs) against a sample of real events. Output: a documented enrichment mapping and a test record showing an alert enriched with owner and criticality.
Set a triage process for vulnerability disclosures
Define how vendor bulletins, supplier notices and third-party advisories reach the security team and how they are sorted. Each disclosure should be checked against the asset inventory to find affected systems, then assigned a priority and an owner for detection rules, compensating controls or patching. Record the time the disclosure was received and the decision taken. Output: a triage procedure, an intake log, and a sample disclosure showing the path from receipt to a documented action.
Curate indicators before feeding detection
Review candidate indicators from your feeds before they reach detection and correlation. Check the source, age, confidence and relevance to your environment, and remove indicators that would produce noise. Platforms such as MISP can correlate exact and pattern-based indicators and export rules, while OpenCTI can organize intelligence as linked entities, but the curation rules are yours to set and document. Output: a curation standard and a record of which indicator sets were loaded into which detections and when.
Feed indicators into detection and correlation
Load approved indicators and intelligence-derived rules into the SIEM or detection tools that watch your logs, such as OpenSearch Security Analytics with Sigma rules or Wazuh with custom rules. Correlate matches with asset context so that analysts see a finding with its affected system attached. Test each new rule against known-benign and known-malicious sample events before it goes live. Output: a change record for each rule set, test results, and a list of detections that now use threat intelligence.
Document how analysts use context in a case
Write a case procedure that tells analysts where to look for threat intelligence, asset context and disclosure records during an investigation, and how to record what they found and how it changed their assessment. Include the sharing rules for any external information used in the case. Review a sample of closed cases to check the procedure is followed. Output: an analyst procedure, a case template with fields for intelligence and asset context, and a periodic review record.
Review sources and rules on a set cycle
Set a recurring review of the source register, enrichment mapping, triage log and detection rules. Remove stale indicators, retire rules that generate no useful findings, and update owners when staff change. Keep the review minutes and the changes made. The NIST Implementation Examples describe three outcomes for DE.AE-07: securely feeding threat intelligence to detection technologies, processes and people, providing asset inventory information to detection, and rapidly analyzing vulnerability disclosures. Your review should show each outcome is still working. Output: signed review minutes and an updated register.
Evidence that shows threat intelligence informs analysis
An assessor testing DE.AE-07 wants to see intelligence moving through the analysis pipeline, not sitting in a platform. Each artifact below shows one link in that chain: which sources feed analysis, how they are shared, what detection logic uses them, what asset context enriches alerts, and how vulnerability disclosures get triaged. Keep them dated and linked to each other so the chain can be followed end to end.
Threat intelligence source register
A register listing each intelligence source, its type, the named owner, the date it was last reviewed and the next review date. Include internal sources such as incident notes and external feeds, and record why each source was admitted. An assessor will check whether sources are still being reviewed, so stale entries with past review dates are a finding in themselves. Confirm the register lives under change control with a history of edits, not as a one-time spreadsheet.
Distribution and sharing rules
Written rules that state which intelligence may be shared with whom, under what marking or sharing group, and whether a managed service provider or peer organization may receive it. These rules should match the platform configuration, such as sharing groups in MISP or connector settings in OpenCTI. Check that restricted indicators are not exported to parties the rules exclude, and keep the rules versioned with an approver recorded.
Exported detection rules and correlation logic
Exports of detection content that reference indicators or intelligence, such as Suricata, Snort or Zeek rules exported from MISP, or Sigma rules in OpenSearch Security Analytics detectors. Each export should carry a source reference and a timestamp so the assessor can trace a rule back to the intelligence that produced it. Store the exports in version control so changes between audits are visible, and confirm which rules are live in production versus only tested.
Asset inventory extracts used for alert enrichment
Extracts from the asset inventory showing which hosts, services and cloud resources were used to enrich alerts, such as owner, criticality or exposure fields attached to a Wazuh alert or OpenSearch finding. DE.AE-07 expects asset data to inform detection, so the extract should show the enrichment fields actually present in alert records. Re-run the extract on a schedule and keep the date with each copy, since an inventory from last year proves little about current coverage.
Vulnerability disclosure triage records
Records of vulnerability disclosures received from vendors, suppliers and third-party advisories, each with the triage decision, the assets checked, the analyst and the date. A record that closes a disclosure as not applicable should state the reason, such as the product version not being deployed. Assessors look for evidence that disclosures are analyzed quickly, so measure the time between receipt and decision against the target your organization set, and confirm that target is written down.
Sample cases showing intelligence applied
Two or three closed analysis cases where an indicator, an inventory field or a disclosure changed the outcome, such as raising severity, widening scope or suppressing a known false positive. An illustrative case might show a feed indicator matching a log entry, the asset record showing the host is internet-facing, and the resulting ticket. Each case should link to the rule, the source and the ticket, so the assessor can follow the path without relying on a screenshot.
What meeting DE.AE-07 threat intelligence costs
This table compares each cost component of connecting threat intelligence, asset inventory and vulnerability disclosures to detection and analysis, showing who is paid, whether the cost is one-time or recurring, and what moves it up or down. Use it to structure a request for quote, since no prices or durations are supplied for this topic and the real figures depend on the written scope and your environment.
| Cost component | Who is paid or who carries it | One-time or recurring | What drives it up or down |
|---|---|---|---|
| Tooling or licenses | Software vendors for commercial threat intelligence platforms or feeds; none for MISP, OpenCTI, OpenSearch or Wazuh licenses | Recurring for commercial feeds and subscriptions; open-source licenses carry no license fee | Number of commercial feeds, feed tiers and seats; confirm any support subscription separately |
| Engineering time to connect feeds | Internal platform team or implementation partner building connectors, parsers and secure feed delivery to detection tools | One-time for initial build, recurring for changes | Number of feed formats (STIX, TAXII, CSV, JSON), normalization needed and whether indicators reach Suricata, Snort or Zeek rules |
| Engineering time to connect asset inventory | Internal or partner engineers feeding asset data into detection, correlation and vulnerability context | One-time for integration, recurring for maintenance | Number of asset sources, inventory accuracy, how often data changes and how many systems lack owners |
| Analyst time to triage intelligence and disclosures | Internal SOC or threat analysts reviewing indicators, false positives and supplier or third-party vulnerability advisories | Recurring | Volume of indicators and advisories, tuning of rules, share of advisories that apply to assets actually in use |
| Evidence upkeep | Internal compliance or security staff keeping feed lists, rule versions, sharing agreements and inventory snapshots current | Recurring | Frequency of assessments, number of distribution groups, and how much evidence is generated automatically from the platform |
| External testing or review | Independent testers or consultants who verify feed handling, detection coverage or rule quality | Recurring if scheduled, one-time for a single review | Scope agreed in writing, number of detection paths tested and whether testing covers only DE.AE-07 or wider detection |
| Auditor sampling | Independent auditor or assessor who samples evidence; the organization pays the auditor, not DeployOpen | Recurring with each assessment cycle | Sample size set by the auditor, quality of records and whether evidence is retrievable without manual reconstruction |
Which open-source tools can produce DE.AE-07 evidence
DE.AE-07 expects threat intelligence, asset context and vulnerability information to shape detection and analysis. No single tool does all three, so the cards below show which open-source platform can produce each kind of record. Each one still needs to be confirmed against your own sources, licensing and operating model before it is cited as evidence.
MISP for indicator correlation
MISP (AGPL-3.0-only) correlates indicators by exact match and by advanced patterns such as fuzzy hashes and CIDR overlaps. It records sightings, which show when an indicator was actually observed in your environment, and exports rules for Suricata, Snort and Zeek through its REST API. Evidence to retain includes event records, sighting logs and exported rule sets with timestamps. Confirm that your version's sharing groups and sync settings match the distribution rules your legal team has approved, and check how AGPL-3.0-only terms apply if you modify and offer the service to others.
OpenCTI for structured intelligence
OpenCTI (Apache-2.0) stores threat intelligence as STIX-based entities, relationships and containers, so analysts can trace which actor, campaign or indicator relates to which report. It ingests data through connectors and TAXII, RSS, CSV and JSON feeds or manual upload. Evidence includes the feed inventory, connector configuration and the reports that show intelligence was reviewed. Confirm which feeds you have approved, how each one is refreshed, and whether your asset inventory and vulnerability sources can be linked to these entities in your deployment.
OpenSearch Security Analytics for detections
OpenSearch Security Analytics (Apache-2.0) runs detectors that match ingested logs from hosts, network devices and cloud services against prepackaged or custom Sigma rules. Matches are recorded as findings with rule, log type and severity, and a correlation engine links findings across log types in a correlation graph. Evidence includes detector definitions, finding history and alert routing records. Confirm which Sigma rules are fed from your threat intelligence, that log sources cover the assets in your inventory, and that the correlation graph reflects the relationships your analysts need.
Wazuh for rule-based alerts
Wazuh (GPL-2.0-only) decodes collected logs and compares each event against a ruleset of over 3,000 built-in rules and decoders plus custom rules. Matching alerts are written to alerts.log and alerts.json, mapped to MITRE ATT&CK and forwarded to the Wazuh indexer for review. Evidence includes rule files, alert records with ATT&CK mappings and agent inventory data. Confirm that the agent inventory is complete for in-scope systems, that custom rules reflect your vulnerability and threat intelligence inputs, and that GPL-2.0-only obligations are reviewed before you distribute any modified components.
Who owns DE.AE-07 and who can help
Your organization owns DE.AE-07. NIST's outcome is that cyber threat intelligence and other context is built into analysis, and that outcome depends on decisions only your staff can make: which intelligence sources you trust, which findings are acted on, and who reviews the analysis when it changes a decision. Accountability for the control stays with a named owner, usually in the security operations or threat management function, with the CISO accountable for the program.
- Control ownership: Name one owner for DE.AE-07 and record how it links to your SOC, vulnerability management and asset inventory owners.
- Source approval: Approve each threat intelligence feed, its licensing terms, its handling rules for sensitive data and the scope of indicators it may push into detection.
- Case review: Require an analyst to review intelligence-driven matches before they change incident handling or risk decisions, and keep the reasoning on record.
- Inventory accountability: Keep the asset inventory current, since DE.AE-07 depends on it to decide whether a vulnerability disclosure matters to your environment.
- Evidence retention: Decide what records you keep, such as feed approvals, rule changes and review sign-offs, and who can produce them.
Check that your owner can explain how a single intelligence item moved from a feed to a decision without outside help.
An implementation partner prepares the systems and evidence that support DE.AE-07 inside your environment. DeployOpen, for example, plans, deploys and documents self-hosted open-source platforms in your own cloud accounts, data centers or air-gapped networks. The partner does not own the control, approve sources on your behalf or decide what counts as a threat for your business.
- Preparing feeds: Stand up threat intelligence platforms, configure connectors and feed ingestion, and set sharing and distribution rules that your owner has approved.
- Connecting inventory and detection: Link asset inventory data and vulnerability disclosures to detection tooling so matches can be prioritized against systems you actually run.
- Assembling evidence: Produce configuration records, rule histories, sample analyses and runbook documentation that show how the control operates.
- Testing the pipeline: Verify that intelligence reaches detection technologies and analysts as designed, and document the results.
- Handover: Train your staff to operate and change the setup so the control does not depend on the partner after delivery.
Scope the engagement in writing and confirm which of these tasks your team will perform after the project ends.
An independent auditor, assessor or certification body tests whether DE.AE-07 operates as described and issues any report or certificate. NIST states that it does not offer certifications or endorsements of CSF implementations and has no conformity assessment program, so no NIST-issued attestation exists for this control. Any formal assurance comes from a body you engage separately, under the terms of the framework or contract that requires it.
- Independence: The auditor must not have designed or built the controls it tests, so partner work cannot substitute for its judgment or sign-off.
- Testing: The auditor samples intelligence-driven alerts, traces them to source approvals and checks that inventory and vulnerability data were used.
- Evidence review: It evaluates whether records are complete, current and attributable to named people.
- Reporting: Only the auditor issues reports, findings or attestations, and the wording of those documents is its responsibility.
- Scope agreement: Confirm with the auditor which framework version, which Subcategories and which assessment method apply before work begins.
Ask any provider to confirm in writing which parts of its work the auditor will rely on and which it will test independently.
Some work around DE.AE-07 is commonly outsourced, while decisions about risk and source trust usually stay in-house. The split depends on your staffing, your regulatory context and how much of the pipeline you want to run yourself. Outsourcing is a choice about labor, not about accountability.
- Commonly outsourced: Initial platform build, feed connector setup, detection content tuning, evidence collection and documentation drafting.
- Usually kept in-house: Source approval, risk acceptance, incident declaration decisions, final case review and communication with regulators or customers.
- Shared work: Inventory accuracy, where your asset owners supply data and the partner integrates it.
- Ongoing operation: Decide whether a retainer covers feed maintenance and rule updates, and who holds administrator access afterward.
- Quote request: Ask providers to separate one-time setup from recurring operation and to state which deliverables transfer to you.
Before signing, confirm that your own staff can perform every in-house task listed here.
Where DE.AE-07 programs usually fall short
DE.AE-07 fails in practice when threat intelligence, asset data and vulnerability disclosures arrive in the SOC but never change how events are analyzed. The gaps below share one root cause: the inputs are collected but not connected to cases, rules and decisions. Each card names the fix and the record an assessor or internal reviewer can check.
Intelligence collected but not applied
Feeds are ingested into a platform, yet no analyst case, alert or enrichment step ever references them. DE.AE-07 expects threat intelligence to be built into analysis, so an indicator store that nobody queries during triage does not meet the outcome. Check whether a sample of closed investigations cites the intelligence used. In MISP or OpenCTI, confirm that indicator matches are logged against the event or case they informed. The fix is a documented triage step that requires an intelligence lookup, with the lookup result recorded in the ticket.
Asset inventory lagging live systems
Detection cannot prioritize an alert if the analyst cannot tell which host, cloud account or device it belongs to, or whether it is in scope. NIST's Implementation Examples for DE.AE-07 call for asset inventory information to reach detection. Compare the inventory export against the live cloud and network discovery results each month and record the differences. The evidence is a reconciliation report with dated exceptions and owners assigned to each gap.
Vulnerability disclosures handled by email
Advisories from vendors, suppliers and third-party sources often arrive in shared mailboxes and are acted on informally. DE.AE-07 covers rapid analysis of these disclosures, so an unrecorded email is not evidence that anyone assessed exposure. Route disclosures into a ticket or case queue with the affected asset list, the analysis date and the decision taken. Confirm that each high-impact advisory has a closed record showing whether a detection rule or patch was applied.
Feeds shared without distribution review
Sharing indicators with peers, an MSSP or an information sharing community can expose sensitive sources, customer data or incident details. Before publishing, check the event's distribution level and the sharing group against the organization's rules. MISP supports granular distribution and sharing groups, so set them per event rather than relying on a global default. The evidence is an approval record for shared events and a log of which sharing groups received each one.
No link between rule and source
A Sigma or Wazuh rule is often written from a blog post, a report or an analyst hunch, and the reason is lost within months. Without that link, nobody can tell whether a rule is still justified or should be retired. Record the intelligence object, report or advisory that motivated each custom rule in the rule's metadata or the ticket that created it. Wazuh custom rules and OpenSearch Sigma rules can carry this context, so review a sample of rules for an identifiable source and a named owner.
Inputs not reviewed for quality
Feeds decay, duplicate indicators and fill the SOC with stale matches. DE.AE-07 does not require any particular feed, but the program should show that intelligence is evaluated before it drives action. Set an expiry or review date for each indicator class, and track how many matches led to a confirmed finding. Ask the team to show the last review of its top feeds and the decision to keep or drop each one.
Common questions about DE.AE-07 threat intelligence
How much effort does meeting DE.AE-07 take?
Effort depends mostly on how many threat intelligence sources, asset inventories and vulnerability disclosure channels you already have, and how many detection tools must consume them. DE.AE-07 is not a single deliverable. It is a set of working flows: feeds reach detection, inventory data reaches analysts and tools, and supplier advisories get triaged quickly. The main cost components are internal staff time to define sources and owners, implementation work to connect platforms, and testing to show the flows work. Most of the effort is one-time setup followed by recurring feed review, rule tuning and inventory upkeep. Ask any partner to break the quote into those components so you can see what recurs.
How long does it take to connect threat feeds and asset inventories?
The timeline depends on the state of your inputs more than on the platform. An organization with a maintained asset inventory and an existing SIEM will connect feeds faster than one that must first build the inventory or agree on which advisories matter. Factors that extend the schedule include access approvals in regulated networks, data quality problems in the inventory, and the number of detection tools that need changes. Ask for a written schedule with milestones for each feed and each data source, and confirm which dependencies sit with your team, such as access approvals and inventory owners.
What does the work need from our internal team?
Your internal team owns the decisions the work depends on. That includes which threat intelligence sources are trusted, who receives vendor and third-party vulnerability advisories, how inventory records are kept current, and what action each intelligence match triggers. An implementation partner can prepare the platforms, connectors and documentation, but it cannot decide your risk appetite or accept your findings. Plan for analyst time to review feed quality, for a named owner of the inventory, and for detection engineers who can maintain rules after handover.
Can a small team meet DE.AE-07 alone?
A small team can meet the intent of DE.AE-07 if it keeps the scope narrow and uses automation for ingestion and matching. NIST's Small Business Quick-Start Guide (SP 1300, February 2024) cites DE.AE-07 when it suggests sharing relevant incident details with an authorized incident responder, such as an MSSP. That suggests that many small organizations will rely on a managed provider for analysis. Whether your team can do it alone depends on how many people can review alerts, how often advisories arrive, and whether someone can maintain the rules. Be candid with yourself about coverage on evenings and weekends before you decide.
What will an auditor sample when testing DE.AE-07?
An assessor typically asks to see how threat intelligence, asset inventory data and vulnerability disclosures actually reach analysis. Expect requests for the list of intelligence sources and their configuration, examples of intelligence matches and what analysts did with them, inventory extracts used during analysis, and records of how supplier or third-party advisories were reviewed. The assessor will check that the flow runs in practice, not only on paper. Prepare dated records, named owners and a sample of closed cases so the evidence can be traced. The specific sample size and method come from the auditor, so confirm them in your engagement letter.
Does NIST CSF 2.0 certification exist, and how does DE.AE-07 relate to it?
No. NIST states that it does not offer certifications or endorsements of CSF-related products, implementations or services, and it has no plans for a conformity assessment program. A CSF 2.0 assessment is therefore a self-assessment or an independent review that you commission, and no body issues a CSF certificate. DE.AE-07 is one Subcategory you can report against in that assessment. If a customer or regulator asks for proof, supply the evidence described above and ask the reviewer to state the scope and method in writing.
What should we ask a partner for in a fixed-scope quote?
Ask for a written scope that names each threat intelligence source, each inventory system and each vulnerability disclosure channel in scope, along with the detection platforms that will consume them. The quote should list deliverables such as configuration, connectors, rule sets, runbooks and evidence packs, and state which items are one-time and which recur. Ask who owns each dependency, what testing is included, how changes after handover are priced and what is excluded. DeployOpen works from a written scope and does not publish a price list, so a clear scope is the basis for any quote. Confirm with your auditor which evidence they will accept.
How DeployOpen prepares DE.AE-07 threat intelligence
DeployOpen plans, implements and documents the self-hosted open-source platforms that feed threat intelligence, asset inventory data and vulnerability disclosures into detection and analysis, inside your own infrastructure. We prepare the systems and evidence for DE.AE-07. Your organization owns the control, and it remains your decision how threat intelligence is used in analysis.
How we scope
- We agree the written scope for DE.AE-07 before work starts, naming the threat intelligence sources, detection platforms and asset inventories in play.
- The scope records which feeds, vulnerability disclosure channels and log sources must be connected, and who in your organization owns each one.
- Engagements are fixed-scope, with deliverables and timelines agreed in writing. Ongoing support is available as a retainer.
How we build
- We deploy self-hosted threat intelligence platforms such as MISP or OpenCTI in your cloud accounts, data centers or air-gapped networks.
- We connect feeds and asset inventory data to detection tools such as Wazuh or OpenSearch Security Analytics, then test that matches produce findings.
- We test how indicators are correlated, how sightings are recorded and how vulnerability disclosures are triaged against known assets.
How we hand over
- We document feed sources, ingestion schedules, correlation rules, access roles and the data flows between intelligence and detection systems.
- We deliver test records showing threat indicators matched to log events and asset records, so an assessor can trace the evidence.
- We walk your security team through the runbooks for updating feeds, reviewing matches and escalating findings to incident handling.
How we support
- Retainers cover upgrades, feed maintenance, rule tuning and periodic re-testing of the DE.AE-07 workflow as your environment changes.
- We can help you prepare the evidence pack for an independent auditor or assessor. We do not issue audit reports or certifications.
- Ask us to confirm in writing which platform capabilities we rely on in your environment before the scope is signed.
