Targeted threat intelligence and scenarios: TIBER-EU requirements

What the targeted threat intelligence step asks for in a TIBER-EU test

When a TIBER-EU or DORA threat-led penetration test starts, the testing phase depends on what this step produces. The threat intelligence provider collects target intelligence on the entity's attack surfaces and exposures and threat intelligence on the threat actors and probable scenarios that matter to it. The output is a longlist of scenarios presented at the scenario selection meeting, and the control team lead must then select at least three of them. Those choices are based on the provider's recommendation, the test manager's input, the red team's view of feasibility, strategic criteria and the entity's size and risk profile. At most one scenario per test may be non-threat-led, which is the optional scenario-X. The targeted threat intelligence report must cover the scope of the research, the actionable intelligence found about the entity, the geopolitical, economic and technological threat analysis, threat actor profiles, and at least three end-to-end scenarios covering availability, integrity and confidentiality. Confirm with your authority whether a generic threat landscape for your financial sector exists, since the framework treats it as highly recommended and it gives the provider a common baseline.

The risk in this step is familiar. A red team test built on generic threats tests the wrong adversary, so the exercise may miss the actors and access paths most likely to reach the entity's critical or important functions. Actionable intelligence is harder to find than the report template suggests. Providers look for leaked credentials, look-alike domains, vulnerable internet-facing systems, and social media and dark web material tied to the entity. Much of this must be verified before it can shape a scenario, and the provider must handle it within the rules set for the test. In a multi-party test that involves an ICT third-party provider, at least one selected scenario should cover that provider's systems, processes and technologies that support critical or important functions, so the entity needs to confirm early what the provider's contract allows the testers to touch.

The second difficulty is agreement. The control team must settle on the scenarios, and the test manager must be satisfied that each one is feasible, proportionate and documented. Entities tend to disagree on which scenarios are realistic for their business, and the discussion often stalls on whether a scenario is too disruptive for production. Prepare a short written rationale for each candidate, record which criteria drove each selection, and agree in advance how scenario-X will be justified if it is proposed. Ask your provider how it will present the longlist, how many candidates it expects to carry forward, and how it will show the evidence behind each actor profile, so the control team can decide on facts rather than instinct.

How the threat intelligence step runs from landscape to approved report

The threat intelligence step turns an optional jurisdiction-wide baseline and entity-specific research into a short list of scenarios and an approved targeted threat intelligence report. Each hand-off has a named owner and a written output that the next step depends on.

Review the generic threat landscape baseline
Where the TIBER authority, the market or both have published a generic threat landscape for the jurisdiction's financial sector, the threat intelligence provider reads it before starting entity research. The report is not mandatory, but it gives every provider a common starting point for the entity-specific work. Where no landscape exists, the provider builds its own view of the sector from open and commercial sources. The output is a provider working note that records which baseline was used, or that none was available.
Collect target intelligence on attack surfaces
The provider maps what the tested entity exposes, including its internet-facing systems, domains, cloud footprint, third-party dependencies and staff online presence. This research stays within the scope agreed in the preparation phase and is passive by design. The output is a catalogue of attack surfaces and exposures, each linked to the critical or important functions and flags it could affect. Confirm with the provider how it handles any data it finds that belongs to individuals or third parties.
Collect threat intelligence on actors and scenarios
In parallel, the provider identifies threat actors that are relevant to the entity, its sector and its region, and works out how each would probably attack. It also considers geopolitical, economic and technological developments that shape the threat. The output is a set of actor profiles and candidate attack scenarios, each tied to an intent that could affect availability, integrity or confidentiality. The provider should be able to show the sources behind each profile.
Present the scenario longlist at the selection meeting
The provider combines the target and threat findings into a longlist of candidate scenarios and presents it at the scenario selection meeting. The control team, the test manager and the red team attend so that feasibility and scope questions can be raised before any choice is made. The output is a minuted longlist with the provider's recommendation and the questions each attendee raised. Ask the provider to show which findings support each candidate.
Select at least three scenarios
The control team lead makes the selection. The lead weighs the provider's recommendation, the test manager's input, the red team's view of feasibility, strategic criteria and the entity's size and risk profile. The selection must include at least three scenarios, and at most one may be a non-threat-led scenario-X. In a multi-party test with an ICT third-party provider, at least one scenario should cover that provider's systems, processes and technologies that support critical or important functions. The output is a signed-off scenario list with the reasons for each choice.
Draft the targeted threat intelligence report
The provider writes the targeted threat intelligence report. It must set out the scope of the research, the actionable intelligence found about the entity (for example leaked credentials, look-alike domains, vulnerable systems and social media or dark web information), the geopolitical, economic and technological analysis, the threat actor profiles, and at least three end-to-end scenarios covering availability, integrity and confidentiality. The control team reviews the draft for accuracy and for sensitive content, and the provider corrects it. The output is a final draft ready for approval.
Approve the report and hand over to red team planning
The test manager reviews the final draft and approves the report. Approval confirms that the scenarios are in scope and that the intelligence is supported by evidence. The control team then plans any leg-ups the red team may need, based on the intelligence. These must not give direct access to flags or disable security controls. The output is an approved targeted threat intelligence report and a leg-up proposal that the red team takes into the test plan.

Which assets, third parties and scenarios the threat intelligence must cover

The provider's research effort follows a handful of scoping decisions made before collection starts. Each decision below changes which attack surfaces, providers and scenarios the targeted threat intelligence report must address, so the control team should settle them in writing before the scenario selection meeting.

Critical or important functions in scope

The functions scoped as critical or important define which business services the threat intelligence must trace back to supporting systems, data and people. Each function needs a clear boundary, because the provider maps attack surfaces and exposures only inside that boundary. Check that every function has named owners, supporting ICT systems and dependencies, and that the list matches the scope specification document. A narrow list keeps research focused, but an incomplete list means scenarios will not test what matters most to the business.

Flags defined per scenario

Flags are the target assets or information the red team must reach to show impact, so they determine which intelligence is worth collecting. Flags that cover availability, integrity and confidentiality each pull in different exposure data, such as credentials for confidentiality or control of processes for availability. Ask the control team to confirm each flag's owner, location and sensitivity before research begins. Vague flags typically lead to broad, costly collection with weak scenario output.

ICT third-party provider systems

In a multi-party test involving an ICT third-party provider, at least one selected scenario should cover that provider's systems, processes and technologies supporting the entity's critical or important functions. This means the provider's exposure, such as shared administration paths, remote access and hosted components, must be researched as part of the target intelligence. Confirm early whether the third party will allow testing, what contractual terms apply and which parts of its environment fall in scope. Without that agreement, the scenario cannot be executed as planned.

Entity size and risk profile

The control team weighs the entity's size and risk profile when choosing among candidate scenarios, since a larger or more exposed organization faces a wider set of threat actors and attack surfaces. Document the reasoning in the scenario selection record, including why the chosen scenarios match the organization's risk appetite. Confirm which threat actors the provider considers relevant to your sector and geography, because this determines how much effort goes into actor profiling compared with exposure discovery.

Attack surface and exposure discovery

Target intelligence covers the entity's attack surfaces and exposures, including internet-facing systems, look-alike domains, leaked credentials, and information about staff on social media or dark web sources. The effort grows with the number of domains, cloud accounts, brands and business units in scope. Ask the provider to state which sources it will use, how it will handle personal data it finds, and how it will confirm findings with the entity before they reach the report.

Optional scenario-X decision

Scenario-X is the one scenario per test that may be non-threat-led, so it is a deliberate choice rather than a default. Deciding whether to use it affects research effort, because a non-threat-led scenario needs less actor profiling but still needs a clear rationale and feasibility view from the red team. Confirm with the test manager whether the scenario is worth its place among the required threat-led options, and record the decision in the report.

How an assessor tests the targeted threat intelligence report

This table sets out what an assessor checks in the targeted threat intelligence report and scenario selection record, the evidence they request, and the gaps they most often find. Read each row as a test step: the check on the left, the evidence that passes it in the middle, and the common failure on the right.

Assessment check	Evidence the assessor requests	Common finding
Report scope of research	Written scope statement covering the entity's systems, functions and sources used for collection	Scope described in general terms without naming the entity's attack surfaces or sources
Actionable intelligence about the entity	Dated findings such as leaked credentials, look-alike domains, exposed systems and dark web mentions, each with source and handling notes	Findings listed without source, date or confidence level, so the assessor cannot trace them
Geopolitical, economic and technological analysis	Section covering the threat landscape relevant to the entity, referencing the generic landscape report where one exists	Generic sector commentary not connected to the entity's own exposure
Threat actor profiles	Profiles naming actors, motivations, capabilities and the entity-specific reason each is relevant	Actors selected from a public list with no explanation of relevance to the entity
Three end-to-end scenarios covering availability, integrity and confidentiality	Scenario summaries showing one scenario per objective, each running from initial access to impact	Scenarios repeat one objective, or cover only confidentiality
Traceable link from scenario to threat actor	Matrix mapping each scenario to the actor profile and the intelligence findings that support it	Scenarios with no traceable link to threat actors or to collected intelligence
Scenario selection record	Minutes of the scenario selection meeting, the provider's longlist, and the reasons for each selection	No record of why scenarios were kept, dropped or ranked, or of the control team lead's decision
Scenario-X count	Confirmation that no more than one non-threat-led scenario is included, with its justification	Two or more non-threat-led scenarios selected, or a scenario-X chosen without strategic reasoning
Test manager approval	Dated approval by the test manager of the final targeted threat intelligence report, with any changes recorded	Report circulated to the red team before approval, or approval missing from the file

How the control team chooses scenarios and when scenario-X is allowed

The control team lead makes the final scenario selection, choosing three or more scenarios from the provider's longlist. The lead does not decide alone. The choice draws on the threat intelligence provider's recommendation, the test manager's input, the red team's view of whether each scenario is feasible against the live environment, strategic criteria set for the test, and the entity's size and risk profile. Before the selection meeting, the control team should confirm that each input is written down, because the assessor will ask how the final three or more scenarios were reached and whether the reasoning can be traced back to those inputs. A decision recorded only as a list of chosen scenarios, with no rationale for the ones rejected, is weak evidence.

Scenario-X is the one scenario that may be non-threat-led, and the framework allows at most one per test. Its use is an exception, so the control team should be able to show why a threat-led scenario could not cover the risk in question and why the non-threat-led one is still worth the red team's effort. The justification should be documented in the targeted threat intelligence report or the scenario selection record, and the test manager's approval of the final report is the point where an assessor will check it. Ask the provider and the control team to confirm, before the meeting, which of the selected scenarios is scenario-X and what risk it targets, so that the rule on the single exception is not discovered late.

An assessor looks for proportionality and traceability. The three-scenario minimum is the only numerical threshold in the framework, so the question is whether the selected set covers availability, integrity and confidentiality and reflects the entity's critical or important functions and its exposure, rather than whether the count is reached. Where the test involves an ICT third-party provider, the assessor will also check that at least one selected scenario covers that provider's systems, processes and technologies supporting those functions. Organizations should plan for the scenarios they rejected to be questioned as well as those they chose, and should keep the reasons with the scenario record.

Evidence that shows the threat intelligence step was done

An assessor or test manager will want to trace every scenario back to the intelligence that produced it. The records below link the collection work, the selection decision and the final approval into one auditable chain. Keep each record dated, versioned and tied to the test it supports, because the 3-year interval between tests is the norm and memories of the reasoning fade quickly.

Signed targeted threat intelligence report

This is the primary artifact. It must cover the scope of the research, actionable intelligence about the entity such as leaked credentials, look-alike domains and vulnerable systems, the geopolitical, economic and technological analysis, threat actor profiles, and at least three end-to-end scenarios covering availability, integrity and confidentiality. Check that the report carries the test manager's approval and the control team's sign-off, with version numbers that match the scenarios later used in the red team test plan.

Longlist and selection meeting minutes

The provider presents a longlist of candidate scenarios at the scenario selection meeting. Minutes should record each candidate, who proposed it, and the outcome. A reviewer will look for evidence that the control team lead made the final choice of three or more scenarios after considering the provider's recommendation, the test manager's input, the red team's feasibility view and the entity's size and risk profile.

Scenario selection rationale

Separate from the minutes, a short written rationale explains why each chosen scenario was kept and why rejected candidates were dropped. Illustratively, a scenario targeting a third-party provider that supports a critical function may be kept because the framework expects coverage of such providers in multi-party tests. Record any scenario-X choice and its justification, since at most one non-threat-led scenario is permitted per test.

Source and collection log

Log every collection activity for target intelligence (attack surfaces and exposures) and threat intelligence (relevant threat actors and probable scenarios). Record the source, date, query or method, and who collected it. If you run MISP or OpenCTI for this work, export the event and container history so each indicator can be traced to its origin. Confirm retention rules for sensitive material such as dark web findings with the provider and your legal team.

Generic threat landscape and approval record

If your jurisdiction produced a generic threat landscape report for the financial sector, file it as the common baseline the provider used, noting who produced it. The approval record then closes the chain, showing who approved the targeted report, when, and under which authority. Ask your authority whether a national generic report exists, because the framework treats it as highly recommended rather than mandatory.

Who does the threat intelligence work and who signs off

The tested entity's control team, led by the control team lead, runs the entity's side of the threat intelligence step. The control team supplies scope information, answers the provider's questions about the entity's attack surface, and takes part in the scenario selection meeting. The lead selects at least three scenarios from the provider's longlist, weighing the provider's recommendation, the test manager's input, the red team's view of feasibility, strategic criteria and the entity's size and risk profile. The control team also plans leg-ups based on the threat intelligence. It must not propose leg-ups that give direct access to flags or disable security controls. The control team does not approve the report it helped shape.

Scenario selection: the lead chooses the final scenarios and records the reasons for each choice.
Scenario-X limit: at most one non-threat-led scenario may be selected per test.
Leg-up planning: the team proposes accesses, devices or information the red team may need, within the framework limits.
Information supply: the team provides the asset, exposure and business context the provider needs.
Confidentiality: the team controls who inside the entity knows about the test.

Before the scenario meeting, confirm with the test manager which scope information the control team must provide and how it is shared.

Open-source tools that support threat intelligence collection and records

Can open-source tools replace a threat intelligence provider for a TIBER-EU test?

No. Open-source tools help the organization and its provider store, correlate and share intelligence, but the targeted threat intelligence report must be written by the threat intelligence provider, who performs the analysis, judges relevance and attributes threat actors. The tools produce records that support that analysis, not the analysis itself. Use them to organize evidence and to make the provider's work traceable, and confirm with the provider which tools and formats it will accept before the collection phase begins.

What does MISP do for indicator correlation and sightings?

MISP is an open-source threat intelligence platform licensed under AGPL-3.0-only. It correlates indicators by exact match and by advanced patterns such as fuzzy hashes and CIDR overlaps, and it records sightings, which document when and where an indicator was observed. These records support the collection record and indicator provenance: who reported an indicator, when it was seen and how it was shared. Confirm with your provider whether its workflow relies on MISP events, so the exported records match what it expects to receive.

How do MISP sharing groups control who sees collected intelligence?

MISP synchronizes events between instances with granular distribution settings and sharing groups, so collected intelligence can be limited to the parties that need it. In a TIBER-EU test this matters because target intelligence can include leaked credentials, look-alike domains and vulnerable systems that should not spread beyond the control team, the provider and the test manager. Define distribution levels in the written scope, record who approved each sharing group, and have the control team confirm that the setup matches the confidentiality rules agreed for the test.

Which MISP export formats feed detection and reporting work?

MISP exports through its REST API to STIX 1 and STIX 2, to CSV, and to Suricata, Snort and Zeek rule formats. STIX exports carry structured threat data into other platforms, CSV supports spreadsheets and review, and the rule formats let the blue team test whether detection content recognizes the indicators used in a scenario. Check the export version and rule syntax your sensors support, and keep the exported files as part of the collection record so the reviewer can trace each rule to its source indicator.

What does OpenCTI do that MISP does not?

OpenCTI, licensed under Apache-2.0, organizes threat intelligence as STIX-based entities, relationships and containers, so threat actors, campaigns, indicators and reports stay linked to each other. It ingests data through connectors and through TAXII, RSS, CSV and JSON feeds or manual file upload, and it shares knowledge through native feeds and exports. Teams often use it to model the relationships behind a scenario, while MISP handles fast indicator matching. Confirm with your provider which platform, or both, it expects so that collection records are not split across tools without a clear reference.

Which records show where a threat indicator came from?

A usable collection record names the source of each indicator, the date it was collected, the collection method, the sharing group and any sightings or corrections recorded afterward. Both MISP and OpenCTI can hold this context when analysts enter it consistently. Good practice is to keep the original feed or file reference, the tool event or container identifier and the analyst decision on whether the indicator was included in a scenario. Ask the provider to explain how it documents provenance so the records can be reviewed during the test manager's approval.

Do the AGPL-3.0 obligations for MISP matter if we modify it?

They can. AGPL-3.0-only requires that if you modify MISP and make it available for users to interact with over a network, you may need to offer those users the source code of your modified version under the same license. Whether this applies depends on how the tool is deployed, changed and exposed, so have counsel review the arrangement before customizing MISP or hosting it for a provider or other parties. OpenCTI is licensed under Apache-2.0, which has different conditions, and both licenses should be checked against your own deployment plan.

Where threat intelligence steps usually fall short

The threat intelligence step feeds every later phase, so a weak report produces weak scenarios and a weak test. The gaps below recur across targeted threat intelligence reports and scenario selection meetings, and each one has a specific check the control team and test manager can apply before approving the report.

Generic threats copied from the landscape

A generic threat landscape report for the jurisdiction is recommended but not mandatory, and it is meant as a common baseline. Provider reports sometimes repeat its threat actor list without showing what is specific to the entity. The fix is to require each threat actor and scenario to cite entity-specific evidence, such as exposed systems, leaked credentials, look-alike domains or the entity's own third parties. The control team should reject any actor whose link to the entity cannot be traced.

Scenarios with no traceable actor

A scenario that describes an attack without naming the threat actor behind it is hard to test for relevance. The targeted threat intelligence report must include threat actor profiles, and each end-to-end scenario should be tied to one or more of them. Ask the provider to show, for each selected scenario, which actor profile it reflects, the source of that profile, and why that actor is probable against this entity. An untraceable scenario should go back for rework before the scenario selection meeting closes.

Missing availability or integrity scenarios

Providers often build most scenarios around confidentiality, such as data theft, and leave availability and integrity underdeveloped. The report must cover at least three end-to-end scenarios that address availability, integrity and confidentiality. Check the longlist and the selected set against those three objectives, and confirm each objective has at least one scenario that reaches a critical or important function. A gap in one objective is a gap in what the test can reveal.

Undocumented scenario-X justification

Scenario-X is a non-threat-led scenario, and a test may include at most one. Entities sometimes select it without recording why a threat-led scenario would not serve the same purpose. The control team should document the strategic or risk reasoning, the feasibility view from the red team, and the link to the entity's size and risk profile. An assessor reviewing the test will look for that record, so keep it with the scenario selection minutes.

Leg-ups that give direct flag access

Leg-ups are the accesses, devices or information the red team receives to reach its objectives. The control team may plan them from the threat intelligence, but a leg-up should not give direct access to flags or disable security controls. Review each proposed leg-up against the flags and the detection controls it would bypass. The test manager approves the final list, so flag any leg-up that removes an attack step the scenario depends on, and send it back for redesign.

No third-party scenario where one is required

In a multi-party test involving an ICT third-party provider, at least one selected scenario should cover that provider's systems, processes and technologies that support the entity's critical or important functions. Entities frequently omit this scenario because the provider sits outside their own estate. Confirm early whether a third-party provider is in scope, agree its participation with the provider, and check the targeted threat intelligence report for at least one scenario that reaches its services.

What the threat intelligence step costs in money and effort

The largest external cost in this step is the threat intelligence provider's fee, which covers collecting target intelligence on the entity's attack surface and exposures, collecting threat intelligence on relevant threat actors, and writing the targeted threat intelligence report. The fee is quoted by the provider, not by DeployOpen or the authority, and it is not a figure this page can give. Ask each shortlisted provider for a written quote that breaks the work into the target intelligence, threat intelligence and report-writing tasks, states how many scenarios and end-to-end attack paths are expected, and says whether the report is updated if the scenario selection meeting asks for more depth. Also ask whether the quote assumes a generic threat landscape baseline already exists or whether the provider must build the context itself.

Some effort is one-time per test and some is reusable. The control team lead's time for the longlist review and the scenario selection meeting, the test manager's review, and the internal effort to gather data for the provider (asset inventories, exposed services, previous findings, third-party dependencies) are paid once for each test. A generic threat landscape report for the jurisdiction's financial sector is not mandatory, but it is a reusable baseline that the authority, the market or both can produce, and each entity saves effort when a current version already exists. Confirm with your authority whether such a report is available for your sector before you ask providers to repeat that work in their quotes. Tooling for threat intelligence, such as MISP or OpenCTI, has its own setup and maintenance effort, and any licensed commercial feed carries a recurring cost that should appear as a separate line in the quote.

Costs rise when the attack surface is large, when the entity has many third parties whose systems must be covered under the scenarios, or when the entity has little existing threat intelligence to build on. Costs fall when the entity keeps an accurate, current asset and exposure inventory and when a generic landscape report is available. Authority review time is usually borne by the authority rather than invoiced, but it can extend the calendar if the report needs revision, so plan for a review cycle and confirm with the test manager how many rounds are expected. Before signing, ask the provider to confirm in writing which deliverables sit inside the fixed fee, what triggers a change request, and who pays for re-work if the report is rejected.

Questions buyers ask about the threat intelligence step

How long does the threat intelligence step take within the testing phase?

The threat intelligence step is one part of the testing phase, which must be followed by at least 12 weeks of active red team testing, so its length is set by the preparation work that comes before it and the testing schedule that follows. The published framework does not give a fixed duration for this step, so ask the provider and the authority to confirm the expected timing in writing. The main drivers are the size and complexity of the entity's attack surface, how many scenarios are longlisted, how quickly the scenario selection meeting can be convened, and how many review rounds the targeted threat intelligence report needs before the test manager approves it. Build the schedule backwards from the agreed start of active testing so that approval of the report is not the step that delays the red team.

Can we run the threat intelligence step in-house?

Your organization can run parts of this step internally, but the framework assigns the threat intelligence work to an independent threat intelligence provider, so an internal team cannot replace that role in a TIBER-EU test. Your control team can supply target information, review the longlist, and help the provider understand your attack surfaces, while your security staff can prepare the data the provider needs. Keep in mind that the control team lead selects the scenarios and the test manager approves the final report, so internal teams carry governance responsibilities even when the research is outsourced. Confirm with your TIBER authority which roles must be filled by independent parties in your jurisdiction before you plan staffing.

What does a threat intelligence provider need from the entity?

A provider needs reliable target information and timely access to the people who can explain your environment. In practice, this means an accurate picture of your external attack surface, internet-facing systems, third-party dependencies, and the critical or important functions named in the scope specification. Expect requests for documentation on exposures you already know about, contacts for questions during research, and clear rules on what the provider may collect and where it may look, including social media and dark web sources. Agree these boundaries in the scoping work, because the provider's collection must stay within the approved scope and legal limits. Ask the provider to list its information requests in writing so your team can plan who responds to each one.

Is scenario-X worth proposing for our test?

Scenario-X is worth proposing only when a non-threat-led scenario answers a specific question about your resilience that threat-led scenarios do not. The framework allows at most one scenario-X per test, and it is optional, so it does not replace the required threat-led scenarios. A useful proposal explains the risk being tested, why a threat actor profile would not capture it, and how the scenario will be evaluated in the red team and blue team reports. Consider whether the scenario adds insight into a critical function, a third-party dependency, or a control you have not tested before. Discuss feasibility with the red team, because the control team lead weighs that view alongside the provider's recommendation and your risk profile before selecting scenarios.

What must the targeted threat intelligence report include?

The targeted threat intelligence report must cover the scope of the research, actionable intelligence found about the entity, the geopolitical, economic and technological threat analysis, threat actor profiles, and at least three end-to-end scenarios. The scenarios must cover availability, integrity and confidentiality, so a report that focuses on only one of these objectives will not meet the requirement. Actionable intelligence examples named in the framework include leaked credentials, look-alike domains, vulnerable systems, and social media and dark web information. Where the test involves an ICT third-party provider, at least one scenario should cover that provider's systems, processes and technologies supporting critical or important functions. Ask the provider to map each section to the framework's requirements before the draft is submitted for review.

Does DeployOpen issue the targeted threat intelligence report?

No. DeployOpen does not produce threat intelligence reports, and it does not issue reports, attestations or certificates for a TIBER-EU test. The threat intelligence provider writes the targeted threat intelligence report, and the TIBER authority and test manager review and approve it. DeployOpen's role is to plan and implement the open-source platforms and evidence systems that support the test, such as a self-hosted threat intelligence platform that stores indicators and sightings within your own infrastructure. Your organization owns its controls and its test outcomes, and any question about the content or approval of the report should go to the threat intelligence provider and your authority.

Can open-source threat intelligence tools support this step?

Open-source tools can store, correlate and share the indicators that feed the threat intelligence work, but they do not perform the provider's analysis or replace the report. MISP, licensed under AGPL-3.0-only, correlates indicators by exact match and advanced patterns such as fuzzy hashes and CIDR overlaps, synchronizes events between instances with sharing groups, records sightings, and exports to STIX, CSV and Suricata, Snort and Zeek rule formats through its REST API. OpenCTI, licensed under Apache-2.0, organizes intelligence as STIX-based entities, relationships and containers, and ingests data through connectors, TAXII and file feeds. Self-hosted deployment keeps sensitive target intelligence inside your environment. Confirm with the provider which platform it can work with and what data handling rules apply before any tool is connected.

How DeployOpen prepares systems and evidence for this step

DeployOpen works on the threat intelligence step as an implementation partner, preparing the self-hosted platforms and the records that the threat intelligence provider and control team use to build the targeted threat intelligence report. DeployOpen does not select scenarios, approve the report or act as the threat intelligence provider, and the entity keeps ownership of those decisions.

How we scope

Engagements are fixed-scope, with the platforms, data sources and deliverables agreed in writing before work starts.
The written scope names which threat intelligence sources, feeds and sharing groups the entity will host and maintain.
Scope also records who on the entity side owns the scenario selection inputs and the approval of the final report.

How we build

Deploy MISP and OpenCTI inside the client's own infrastructure, with access limited to the parties named in the scope.
Configure feeds, connectors and sharing groups so collected target and threat intelligence is organized by entity and source.
Set up logging and retention so every collected item can be traced back to its source for the provider and assessors.

How we hand over

Provide documented configurations, data source inventories and access records that support the targeted threat intelligence report.
Deliver export routines so indicators and reports can be shared with the provider and the test manager in agreed formats.
Hand over a runbook describing ownership, update cadence and how the entity can reproduce the intelligence collection.

How we support

Ongoing support, upgrades and continuous testing are available as retainers after the initial handover.
Support can cover platform updates, feed maintenance and changes to the scope if the test timeline shifts.
Confirm with your provider and auditor which evidence formats they accept before the scenario selection meeting.