Open source threat intelligence for ISO 27001 control 5.7: what the control asks for
An ISMS owner preparing for certification needs evidence that threat intelligence is collected, analyzed and acted on, and a self-hosted MISP or OpenCTI instance can produce the records that show it. The control itself, however, is met by the organization's process: who decides what intelligence is needed, who reviews incoming information, and how findings change controls. The tool keeps the trail, but the auditor will test whether people used it. Annex A control 5.7 in ISO/IEC 27001:2022 asks the organization to collect information about information security threats, analyze it to produce threat intelligence, and use that intelligence so it understands its threat environment and can take mitigating action. ISO/IEC 27002:2022 gives guidance on the control and describes intelligence at three levels: *strategic* information about the changing threat landscape, *tactical* information about attacker methods, and *operational* information about specific attacks and indicators. A defensible design shows all three levels, with a named owner for each and a documented link to decisions such as risk treatment under clause 6.1.2 and vulnerability priorities under A.8.8.
Two points set expectations for the audit. First, ISO does not certify organizations; accredited certification bodies do, and they test the control against your documented process and records rather than against a product name. Second, the control sits next to A.5.6 on special interest groups and A.8.16 on monitoring, so the same platform often serves several controls. Confirm with your certification body how they expect the three levels to be evidenced, and whether they want sharing community membership documented separately from internal analysis. Before you budget for deployment, decide what the platform must prove. Ask your ISMS owner for the intelligence requirements, the roles that consume each level, and the review cadence. Then check the current MISP and OpenCTI documentation for the version you plan to run, since OpenCTI releases and licensing differ by edition and MISP 2.4 is end of life for new installs.
Mapping A.5.7 and related clauses to what the platform must do
This table maps A.5.7 and four closely related requirements to the work the platform must support and how MISP or OpenCTI is configured to produce that work. Read each row as a question an assessor may ask, followed by the configuration that gives you a defensible answer. The main takeaway is that A.5.7 is served by the whole collection, analysis and action cycle, so the evidence has to show use of intelligence, not just a feed count.
| Requirement | What the function must do | How to configure MISP or OpenCTI |
|---|---|---|
| A.5.7 Threat intelligence | Collect threat information, analyze it into intelligence and act on it so the organization knows its threat environment | Define consumers and intelligence requirements, enable feeds and sharing communities, tag events with taxonomies and galaxies, and record the action taken on each relevant event |
| Clause 6.1.2 Information security risk assessment | Feed current threat information into risk identification and treatment decisions | Link threat actors and ATT&CK techniques in MISP galaxies or OpenCTI reports to the risk register entries they affect, and keep the link dated |
| A.5.6 Contact with special interest groups | Maintain contact with sharing groups and specialist bodies that supply threat information | Create one sharing group per community, set distribution levels and TLP markings, and keep the membership and synchronization records for each community |
| A.8.8 Technical vulnerabilities | Connect threat information about exploited vulnerabilities to the vulnerability process | Tag vulnerability events with CVE identifiers and exploitation status, then pass those records to the vulnerability management tool so patching priority reflects active threats |
| A.8.16 Monitoring activities | Turn indicators into monitored detections and review the results | Export MISP attributes to Suricata and Zeek formats, push indicators into the SIEM, and log which indicators were deployed, when and by whom |
| Evidence an assessor expects | Proof that intelligence was collected, analyzed, shared and acted upon, with dates and owners | Retained events with timestamps, sharing group membership lists, feed inventory, export logs and records of decisions made from intelligence |
MISP or OpenCTI: which fits which ISMS
Choose MISP when the main value of the program is exchanging indicators with peers, sector groups or a national community. MISP is an open source platform for collecting, storing, distributing and sharing cyber security indicators, licensed under the GNU AGPL version 3. Its strength is distribution control: sharing decisions are made per event and per attribute, so analysts can keep sensitive material inside the organization while still publishing low-sensitivity indicators to partners.
- Distribution levels: Set the audience for each event and attribute, and use custom sharing groups when a subset of partners needs material that others should not see.
- Synchronization: Automatic sync between MISP instances lets you join or host trusted communities without manual file exchange.
- Export formats: Indicators can be exported to Suricata, Snort, Zeek and RPZ, and to STIX 1 and 2, which covers most sensor and partner tooling.
- Recommended version: MISP 2.5 is the recommended version for new deployments, and MISP 2.4 is end of life with security fixes only.
- Licensing: The software is AGPL-3.0 and taxonomies and galaxies carry separate CC0 or BSD terms, so confirm both before redistributing data.
Before you join a community, confirm with the community operator which distribution levels it accepts and who approves new members.
Choose OpenCTI when analysts need to model threat actors, campaigns, malware and infrastructure as linked objects and trace how they relate over time. OpenCTI structures data with a knowledge schema based on the STIX2 standards and exposes a web application and GraphQL API. The Community Edition is licensed under Apache License 2.0. The platform is heavier to run than a sharing-first MISP instance, because it depends on several supporting services that must be sized and maintained together.
- Data model: Relationships between actors, intrusion sets, tools and observables are first-class, which supports strategic and tactical reporting.
- Search and storage: Elasticsearch 8.0 or OpenSearch 2.9 or later, Redis 7.1 or later, RabbitMQ 3.11 or later and S3-compatible storage such as MinIO are required dependencies.
- Workers and connectors: Python workers consume RabbitMQ messages, and connectors handle import, enrichment and export, so each connector needs an owner.
- ATT&CK mapping: A dedicated connector brings the MITRE ATT&CK framework into the knowledge base.
- Versioning: Regular releases follow a date-based pattern, and LTS releases are offered on a six-month cadence with a license key requirement.
Before you commit, ask your partner to size the dependency stack for your expected volume and to name who patches each component.
The OpenCTI Enterprise Edition is a separate, proprietary license from the Community Edition. You need to decide whether any feature or support term your program depends on sits behind it. Licensing is a procurement and legal question, separate from the control itself: ISO/IEC 27001 control A.5.7 asks for collection, analysis and action on threat information, and it does not require a particular license tier. A Community Edition deployment can produce the same evidence if the process around it is documented and run.
- Feature gap check: Compare the features your use cases need against the Community Edition and the Enterprise Edition documentation before you decide.
- LTS access: OpenCTI LTS releases require a specific LTS license key to use, so an LTS-based support model needs that key in the budget.
- Support terms: Vendor support, service levels and roadmap commitments belong to the commercial agreement, not to the open source code.
- Audit trail: Record the license terms and decision in the ISMS documentation, so an auditor can see why the edition was chosen.
- Exit path: Confirm the data export options if you later move between editions or platforms.
Ask the vendor in writing which features and support terms your scope needs, then compare that list with the Community Edition before signing anything.
Both platforms can support control A.5.7 when the program has defined intelligence requirements, documented sources and a repeatable process for acting on what is collected. The choice is less about which platform is better and more about which evidence your team can produce and keep current. ISO does not certify organizations, and certification bodies assess the ISMS against the standard, so the platform choice should be explained in terms of your own process.
- Requirements first: Document the strategic, tactical and operational intelligence your consumers need, then map each need to a platform capability.
- Operating capacity: Consider who will curate indicators, age out false positives and maintain connectors, because the platform does not do this alone.
- Sharing obligations: If your organization must share with a community, MISP's model may fit those arrangements more directly.
- Hybrid option: Some organizations use MISP for exchange and OpenCTI for analysis, which adds integration work and a second system to evidence.
- Evidence trail: Keep logs of feeds, imports, sharing decisions and actions taken, regardless of platform.
Check the choice with your certification body or internal auditor before you finalize the design, since they will judge the evidence rather than the product.
Which open source platforms support the threat intelligence evidence trail
A threat intelligence evidence trail for A.5.7 runs from collection to a documented action. No single product covers that chain, so the cards below group the platforms by the role each plays: the intelligence store, the sensors that act on indicators, the SIEM that correlates them, and the workflow that records the response.
MISP as the intelligence store
MISP is the system of record for indicators, events and sharing decisions. It is licensed under AGPL-3.0, and MISP 2.5 is the recommended line for new deployments, with 2.5.50 the latest supplied release. Its distribution levels and sharing groups record who may see each indicator, which is the evidence an auditor asks for when reviewing how intelligence is shared. Check which MISP version and PostgreSQL or MySQL backend your upgrade path will use.
OpenCTI for strategic and tactical analysis
OpenCTI holds the analyst view: threat actors, campaigns, intrusion sets and their relationships, structured on the STIX2 standards. The Community Edition is licensed under Apache-2.0, while the Enterprise Edition carries a separate license. Confirm which features your analysts need before choosing the edition, because the audit trail of analytical judgments depends on them. Its LTS releases also require a license key, which should be part of the operating plan.
Suricata and Zeek for sensor-side use
Suricata and Zeek turn exported indicators into detections on network traffic, which is where operational intelligence is acted on. Suricata 8.0.7 is licensed under GPL-2.0 and Zeek 9.0.0 under a BSD-style license. MISP exports to Suricata, Snort and Zeek formats, so the record of which indicator became which rule can be kept. Ask who approves each rule push and how false positives are reviewed before they block traffic.
Wazuh or Security Onion for correlation
A SIEM or monitoring platform correlates imported indicators with logs, showing whether a threat ever touched the estate. Wazuh is licensed under GPL 2.0 and Security Onion under the Elastic License 2.0, and Security Onion bundles Suricata, Zeek and osquery. The license terms differ in ways that matter for redistribution and managed service delivery, so have counsel confirm them. Record the matches and the alerts they raised as part of the evidence trail.
Shuffle for enrichment and response records
Shuffle, licensed under AGPL-3.0, runs enrichment and response workflows that link an intelligence item to a ticket and to the action taken. Each workflow run is a timestamped record that can show when an indicator was enriched, who approved a block and what changed. Confirm how Shuffle workflow history is retained and exported, and whether it writes back to MISP or OpenCTI so the two records stay consistent.
How to configure the platform so the records support A.5.7
The sequence below turns a bare MISP or OpenCTI install into a governed intelligence process, where each collected item carries a source, a sharing rule, an analyst decision and an expiry date that an auditor can trace back to the requirements. The output is a set of configuration records and a running log that together show A.5.7 is operating, not just installed.
Define intelligence requirements and consumers
Before any feed is connected, the security lead writes down which threats the organization needs to know about, grouped into strategic (changes in the threat landscape for leadership), tactical (adversary behaviors, mapped to MITRE ATT&CK where possible) and operational (indicators for detection and blocking). Each requirement is paired with a named consumer, such as the SOC, the risk team or the CIO. The sign-off is a short, dated requirements document that links back to the risk assessment under clause 6.1.2. Confirm the requirements with the risk owner before moving on, because every later record should trace to one of them.
Select feeds and sharing communities
The team chooses the external sources to subscribe to and the sharing communities to join, then records the reason for each against a requirement. MISP ships with default intelligence feeds, but each one should be reviewed for licensing, update cadence and relevance before it is enabled. Commercial or paid feeds are a separate contract and cost line. The output is a source register listing each feed or community, its owner, its license terms and the requirement it serves. Membership in sharing communities is also linked to A.5.6, so record the group names and the contact points.
Deploy MISP 2.5 and confirm version status
For a new deployment, the platform team installs MISP 2.5, which the project recommends for new instances. MISP 2.4 is end of life with security fixes only, and the project strongly advises against installing new 2.4 instances, so an existing 2.4 system should be scheduled for upgrade. The project's download page lists an installer for Ubuntu 24.04, along with Docker images, Ansible roles, Puppet and RPM packages. Record the installed version, the installation method and the date of the last security update in the change log, because auditors will ask which version was running during the assessment period. Confirm the chosen version against the MISP download page at the time of install.
Configure sharing groups and distribution levels
The team defines distribution levels and custom sharing groups so that each event and attribute is shared only with the audience its source and sensitivity allow. Sharing rules are set per attribute where needed, and Traffic Light Protocol markings are recorded alongside. Trusted communities and synchronization partners are added only after their rules are written down. The check is a test event, created with a restricted distribution, that is confirmed as invisible to an account outside the group. Keep the sharing matrix as a controlled document, since it is direct evidence of how information is protected when exchanged.
Set up correlation, enrichment and export
The team enables the correlation engine so that new attributes are matched against existing events using exact matches and advanced patterns such as fuzzy hashes and CIDR overlaps, with the controls set for each attribute type. Taxonomies, warning lists and galaxies are enabled to standardize tagging against threat actors, malware and MITRE ATT&CK. Export formats are then mapped to consumers: Suricata and Zeek rules for network sensors, STIX for partners, and CSV or the API for the SIEM and SOAR. The output is a documented export list, with a test export to each consumer that is logged, so the team can show intelligence reaches the controls it is meant to inform.
Define review, curation and aging rules
Indicators decay, so the team sets written rules for how long each attribute stays active, who reviews it, and what happens when it is challenged. Typical rules separate indicators by type, record the analyst who approved each publication, and flag false positives so they are removed from exports. The rules are approved by the security lead and reviewed on a fixed schedule. Confirm that the review cycle is tied to the consumers in step one, since a stale indicator blocking legitimate traffic is a control failure, not only a data quality issue.
Record every action in a traceable log
The final step is to keep an evidence trail. MISP and the SIEM or SOAR logs should capture event creation, publication, sharing changes, exports and deletions, and the team should retain them in line with the organization's log retention policy. A simple register links each intelligence item to its requirement, source, sharing rule, analyst and export. The check is a sample walk-through: pick one indicator and show the path from requirement to source to export to outcome. Ask your implementation partner to confirm that the logging configuration is in place and that the register can be produced on request for the certification body.
Evidence auditors ask for under A.5.7 and which component produces it
This table maps each evidence item an assessor may ask for under Annex A 5.7 to the platform component that usually produces it, and what the reader must confirm in their own environment. Read it as a checklist for the evidence pack: the component is a starting point, and the record only counts if its retention, access and sign-off are defined. The main takeaway is that MISP and OpenCTI produce much of the analysis trail, but decisions and effectiveness reviews often live in documents and tickets outside the platform.
| Evidence item | Producing component | What the reader must confirm |
|---|---|---|
| Intelligence requirements | Documented requirements register, referenced from MISP or OpenCTI tags and report templates | Who approves requirements, how often they are reviewed, and which consumers each requirement serves |
| Source register | MISP feed and sync configuration, OpenCTI connector list and their configuration exports | Every feed and sharing community is listed with owner, licence terms, and the date it was approved for use |
| Collection logs | MISP feed fetch and sync job logs, OpenCTI connector and worker logs, retained in the central log store | Log retention period, whether logs are shipped off the platform host, and that collection failures generate an alert |
| Analysis and tagging records | MISP events and attributes with tags, galaxies and correlations; OpenCTI reports, notes and relationships | Analyst identity is recorded on each change, and tagging follows a written taxonomy agreed with the team |
| Dissemination decisions | MISP distribution levels and sharing groups; OpenCTI marking definitions, with the approval recorded in a ticket or memo | Who may approve sharing outside the organization, and how TLP and sharing rules are applied and checked |
| Actions taken on indicators | SIEM tickets and firewall or sensor rule changes linked back to the MISP event or OpenCTI indicator | Each indicator that drives a block, detection or hunt carries a traceable reference to the action in the response system |
| Review of effectiveness | Periodic review record in the ISMS documentation, supported by indicator ageing and hit statistics from the platform | Review frequency, owner, and whether findings feed back into requirements and feed selection |
What tooling alone does not satisfy
A self-hosted MISP or OpenCTI instance supports control A.5.7, but the control is owned by a documented process. The cards below describe the gaps auditors tend to find when a platform is running but nobody can show how intelligence was requested, vetted, assessed and acted on.
No defined intelligence requirements
A.5.7 expects the organization to collect information about threats so it can understand its threat environment. Without written intelligence requirements that name the consumers, such as the SOC, risk owners and engineering, feeds get added by default and nobody can say why a given source matters. Check that each feed and sharing community traces back to a stated requirement and an owner who reviews it.
No named analysts or review cadence
Intelligence that no one reviews does not reach the people who can act on it. A MISP or OpenCTI instance needs named analysts who triage incoming events, decide what becomes an indicator, and record the decision. Confirm who holds each role, how many hours it takes to cover it, and how often the team reviews open items and reports to management.
Unvetted feeds and sharing rules
Default feeds and community synchronization bring in data of unknown quality and sometimes restricted distribution. Before enabling a feed, record its source, licence, reliability and the distribution level or sharing group that applies to its data. Check that TLP markings are enforced on export and that no restricted indicator reaches a partner community by mistake.
No link to risk assessment
Clause 6.1.2 requires an information security risk assessment, and threat intelligence should feed it. If intelligence stays in the platform and never reaches the risk register, the organization cannot show that threat information changed a risk rating or a treatment decision. Check that the risk assessment method names the intelligence sources it uses and that significant changes are recorded with their source.
Missing evidence retention
An auditor asks for proof that the process ran over the whole review period, not a screenshot of the dashboard. Keep exported reports, review minutes, sharing agreements, access records to the platform and decisions on indicators. Confirm the retention period with your compliance lead and test that old events, audit logs and backups can still be restored.
OpenCTI Enterprise features not licensed
The OpenCTI Community Edition is Apache-2.0 licensed, while the Enterprise Edition runs under a separate proprietary license. If the process depends on a feature that sits only in the Enterprise Edition, the design fails when the license lapses or was never bought. List every required capability before choosing the edition, and confirm with Filigran which features need the Enterprise license in the current release.
Questions buyers ask before hiring help for A.5.7
What drives the cost of a self-hosted MISP or OpenCTI deployment?
Software licensing is not the main cost driver: MISP is licensed under AGPL-3.0, and OpenCTI ships a Community Edition under Apache License 2.0. Cost sits in four places: the infrastructure OpenCTI needs (Elasticsearch or OpenSearch, Redis, RabbitMQ and S3-compatible storage), connector and integration work into your SIEM, firewalls and SOAR, paid feeds you choose to subscribe to, and analyst time spent curating indicators. Infrastructure and curation recur every year, while setup and integration are mostly one-time. If you are considering OpenCTI Enterprise Edition, that is a separate license under its own terms. Ask any partner for a quote that lists each component, who pays for it, and which items are one-time versus recurring.
How long does a threat intelligence rollout take?
Duration depends on scope, not on the software: the number of feeds and sharing communities, how many systems must receive indicators, whether OpenCTI needs a multi-node cluster, and how quickly your team can approve sharing rules. MISP 2.5 is recommended for new deployments and is installed on Ubuntu 24.04 with the provided installer, which keeps the platform step short. Connectors, detection-tool exports and governance usually take longer. Ask for a timeline in the written scope, with milestones for platform build, feed onboarding, integration testing and first supervised sharing.
What does our team need to provide during the engagement?
You will need to supply named owners for intelligence requirements, a decision on which sharing communities you will join, your TLP and distribution rules, access to the SIEM, firewall or SOAR systems that will consume indicators, and a hosting environment that meets your data handling policy. Analysts must agree how indicators are scored, aged out and reviewed. Without these inputs, the platform will run but will not produce evidence that your A.5.7 process works. Ask the partner to list every client dependency in the written scope so that delays have a clear owner.
Can our own team run this in-house instead of hiring a partner?
Yes, many teams do, provided they have engineers who can operate PHP and MySQL or MariaDB with Redis for MISP, or Elasticsearch or OpenSearch, Redis, RabbitMQ and object storage for OpenCTI. The harder part is ongoing operation: upgrades (MISP 2.4 is end of life with security fixes only), connector maintenance, backups and analyst workflows. A partner is usually considered when the team lacks capacity for those tasks or needs an independent build. Compare the internal effort against a written scope from a partner, and confirm that your staff can sustain the upgrade cadence.
Is MISP or OpenCTI better for ISO 27001 evidence?
Neither platform is better for A.5.7 by default. The control asks you to collect and analyze threat information and act on it, so the right choice depends on your workflow. MISP is strong at collecting, sharing and distributing indicators, with distribution levels, sharing groups and exports to Suricata, Snort, Zeek and STIX. OpenCTI structures data on the STIX2 standards and supports knowledge modeling across strategic, tactical and operational levels. Many teams use both. Decide which records you need to show an auditor, such as feed lists, analysis notes and action logs, and test that the chosen platform produces them.
Does a threat intelligence platform alone get an organization ISO 27001 certified?
No. ISO does not certify organizations, and a platform cannot be certified on its own. Certification is issued by an accredited certification body after an audit of your information security management system, including the risk assessment, policies, roles and records. A platform can produce evidence for A.5.7, such as feed inventories, analysis records and actions taken, but the auditor decides whether that evidence is sufficient. Ask a partner which evidence is produced by the system and which must come from your processes, and confirm the current audit requirements with your certification body.
What ongoing support do we need after go-live?
Plan for recurring work in four areas: platform upgrades, connector and feed maintenance, backups and restore testing, and curation of indicators. MISP releases and OpenCTI releases both change frequently, and OpenCTI LTS releases require a specific LTS license key and receive only critical bug and security fixes after stabilization. Ask whether a support retainer covers upgrades, monitoring and connector updates, and whether it is fixed-scope or open-ended. DeployOpen offers ongoing support and upgrades as retainers, and quotes follow from a written scope.
How certification bodies check threat intelligence evidence
Certification bodies do not certify a control because a platform exists. They check that the ISMS has run the threat intelligence process over time, which is why the audit cycle matters more than the software. Under ISO/IEC 17021-1, a management system certification cycle lasts three years, with at least one audit, surveillance or recertification, in every calendar year. For A.5.7, that means the auditor expects to see MISP or OpenCTI records from several different periods, not one set of feeds loaded before the first visit. Accredited certification bodies also now apply ISO/IEC 27006-1:2024 to all clients, a requirement IAF MD 29:2024 set for a deadline of 31 March 2026. Confirm with your certification body how it has applied that transition to your scope and audit plan.
Auditors sample records. They will usually ask for a selection of intelligence items, the decisions taken from them, and proof that the decisions reached the right owners, such as SOC triage, vulnerability management under A.8.8 or the risk register under clause 6.1.2. A screenshot of the MISP or OpenCTI dashboard shows that the tool is installed, but it does not show that a specific indicator was reviewed, classified, shared under a stated TLP or distribution level, or acted on. Your evidence pack should therefore be built from the platform's own audit trail, exported event histories, sharing group settings and ticket references, and each sampled item should be traceable from source to action. Ask your implementation partner which logs the platform keeps, how long they are retained, and how they are exported for the auditor.
Plan the evidence before the first audit year, not during it. Decide which review cycle you will record (for example, a weekly triage review of new events and a quarterly review of strategic summaries), who signs off each cycle, and where the minutes are stored. Test the export by pulling a sample of events with their timestamps, users and actions, and check that the output reads without the platform open. Confirm with your certification body which records it will accept as evidence and in what format, since the required depth depends on your scope, your risk assessment and the audit plan agreed for your organization.
How DeployOpen scopes and delivers the threat intelligence function and its evidence
DeployOpen plans, implements, customizes, integrates, hardens, documents and supports self-hosted MISP or OpenCTI inside your own infrastructure, so the intelligence records and sharing configuration stay under your control. We prepare the systems, controls and evidence for A.5.7 so your team and your independent certification body can review them.
How we scope
- Engagements are fixed-scope, with the platform choice, sources, sharing rules and deliverables agreed in writing before work starts.
- The written scope names which threat intelligence levels (strategic, tactical, operational) the platform must serve and who consumes each output.
- Scope also records which feeds, sharing communities, SIEM and firewall integrations and TLP rules are in or out, with the owner of each.
How we build
- We deploy MISP or OpenCTI with the dependencies its documentation requires, configured for your hosting, network and data residency constraints.
- Sharing groups, distribution levels and feed ingestion are configured and tested against the rules agreed in the scope document.
- Integrations that push indicators to detection tools are tested end to end, with the results recorded as part of the evidence pack.
How we hand over
- You receive documentation of the intelligence workflow: collection, analysis, triage, dissemination and review, mapped to A.5.7 and related controls.
- Runbooks cover feed onboarding, indicator aging, false positive handling and sharing approvals so your analysts can operate the platform.
- Evidence is organized for assessment, including configuration records, sharing logs and review minutes. Your auditor decides what is sufficient.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers, including tracking of MISP and OpenCTI release lines.
- Upgrades are planned against the vendor's release and life cycle documentation, with changes to sharing and integration settings re-tested.
- Before your certification cycle, we can review the evidence set against the scope so gaps are found and addressed by your team.
