How MISP helps with ISO 27001 A.5.7 threat intelligence
MISP can hold the collection, analysis and sharing records behind ISO/IEC 27001:2022 control A.5.7, but it does not produce an ISMS decision and it cannot certify anything. The ISMS owner still has to decide what threat intelligence the organization needs, act on it and show an accredited certification body that the process runs as described. Think of MISP as the system of record for the technical part of the work, with the management part documented alongside it. The control asks the organization to collect information about information security threats, analyze it to produce threat intelligence and use that intelligence to take mitigating action. MISP supports the collection and analysis steps directly. Feeds, community sharing and imported reports land as events and attributes, the correlation engine links related indicators, and tags from taxonomies and galaxies, such as MITRE ATT&CK, record how each item was classified. Event history and sharing settings show what came in, from where and who received it. Several parts depend on people and process rather than the platform. Someone has to decide which sources are trusted, who triages new events, how a finding turns into a mitigating action in the ISMS, and how the organization reviews whether the program works. MISP can show that an event was created and shared, but it cannot show that a sensible response followed unless your procedures require and record that step, for example in a linked ticketing system. The standard's wording is described in the researched material only in general terms. Read the control text, its attributes and purpose in your licensed copy of ISO/IEC 27001:2022 before you map MISP records to it, and confirm with your certification body how it expects threat intelligence to be evidenced. Certification decisions are made by an accredited certification body, not by ISO and not by DeployOpen. For planning, list the claims you expect to make for A.5.7, then trace each one to a MISP record such as an event, a sharing group, an audit log entry or an exported report. Anything you cannot trace to a record needs a procedure or a manual log. Confirm with your certification body which evidence it accepts before you build the workflow, because that conversation shapes what the platform needs to retain.
Mapping A.5.7 and its NIST crosswalk to MISP capabilities
This table maps the threat intelligence activities that A.5.7 describes, and the related NIST SP 800-53 items in the NIST crosswalk, to MISP features and the configuration each one needs. Read each row as a question an assessor may ask, with the MISP setting that answers it and the records that show it. The main takeaway is that most of the evidence comes from configuration choices you make and document, not from the software alone.
| Requirement | MISP capability | Configuration needed |
|---|---|---|
| Collection of threat information (feeds and imports) | Default intelligence feeds, feed fetching and manual or automated imports of events and attributes | Enable the feeds you have approved for use in the feed list, record each feed's source and owner, and set a fetch schedule. Import local incident data through a documented import procedure. |
| Analysis to produce intelligence (correlation, galaxies and taxonomies, warning lists) | Correlation engine, MISP galaxies (threat actors, malware, ransomware, tools, MITRE ATT&CK), taxonomies and warning lists | Turn on correlation for the events you analyze, enable the galaxy and taxonomy sets you use, and enable warning lists so known benign values are flagged before they are published. |
| Awareness of the threat environment and mitigating action (distribution levels, sharing groups, synchronization, exports to detection tools) | Distribution levels per event and attribute, custom sharing groups, synchronization with trusted communities, and exports such as Suricata, Snort, Zeek and RPZ | Define one sharing group per trust relationship, set a default distribution level for new events, configure sync servers with matching filters, and schedule exports to the detection tools your team runs. |
| NIST PM-16 Threat awareness program | Shared event records, feeds and community sharing that give a repeatable view of threats relevant to the organization | Document which feeds, communities and internal event types form the program, assign an owner for each source, and keep a review log of feed changes. |
| NIST PM-16(1) Automated means for sharing threat intelligence | Automatic synchronization, the restSearch API and the bundled PyMISP library for scripted exchange | Enable synchronization with each approved partner instance, set a pull and push filter per sharing group, and store API keys with an owner and rotation record. |
| NIST RA-10 Threat hunting | Correlation results, attribute search and exports to log and detection platforms used for hunting | Connect MISP exports to your SIEM or detection tools, keep hunting queries and their results as saved searches or tickets, and record which indicators were searched and when. |
How feeds, communities and correlation produce the intelligence
The chain an auditor will want to follow runs in one direction: information enters MISP, becomes structured records, is linked to related records, is enriched with context, and then leaves the platform for use by detection tools. Each link in that chain is a place where the organization makes a decision and where evidence should exist. Map the chain before the first auditor walkthrough, so that every stage can be shown with a real record from your own instance rather than described from a diagram. Information arrives from three kinds of source: commercial or public feeds, peer communities and trusted sharing partners, and your own analysts who report what they see during investigations. MISP stores this material as events, which hold the context of a report, and attributes, which hold the individual observables such as IP addresses, domains, file hashes and email addresses. Confirm which feeds are enabled, who approved each one, and what each feed is expected to contribute. A feed list that nobody can justify is hard to defend in an assessment of A.5.7.
The correlation engine is where raw items become intelligence. It links attributes that match exactly and, under its advanced patterns, links fuzzy hashes and CIDR network overlaps. Those settings change how many links appear and how much analyst time follows. Fuzzy matching and broad CIDR overlaps can produce useful leads and also noise, so the organization should decide which attribute types are correlated, at what level of matching, and who reviews the resulting links. Record those decisions as configuration baselines, with the date and the approver, because they shape every downstream output. Galaxies and taxonomies add context that analysts and detection engineers can act on. MISP ships galaxies covering threat actors, malware, ransomware, tools and MITRE ATT&CK, along with taxonomies and warning lists. Their licenses are separate from the AGPL software license: MISP taxonomies and galaxy data are licensed under CC0 1.0 Universal or the 2-clause BSD license. Confirm which galaxy and taxonomy versions are loaded and keep a record of updates, since enrichment that changes silently makes past conclusions hard to reproduce. Results leave MISP through exports such as STIX, Suricata, Snort, Zeek and RPZ, or through API queries that a detection tool or SIEM runs on a schedule. Each export or query path is an interface that needs an owner, an approval for what is shared, and a log that shows what was sent and when. Those logs, together with the events themselves, are the records that show the control operating. ISO/IEC 27002:2022 describes threat intelligence at three levels: strategic (the changing threat landscape and business impact), tactical (attacker methods and behavior) and operational (specific indicators and technical details of attacks). MISP is strongest at the operational level and covers part of the tactical level through galaxies and event narratives. Strategic assessment usually lives in reports, risk registers and management reviews outside MISP. Document that split explicitly so that an auditor does not expect MISP to hold material it was never designed to contain.
Configuring MISP so its records show a working intelligence process
This sequence turns a new MISP instance into one whose records show a working threat intelligence process. Each step produces a configuration baseline, an access record, an approval or a decision log that an auditor can sample against A.5.7. Work through the steps in order, because sharing, feed and correlation decisions depend on the identity model and information classification set earlier.
Confirm the MISP version and installation method
The platform engineer confirms that the instance runs MISP 2.5, the version the project recommends for new deployments, and records the installation method. Options include the installer for Ubuntu 24.04, Docker images, Ansible roles, Puppet and RPM packages. Confirm the support terms and upgrade path for the chosen method against the current download page before build. Record the version, operating system and deployment method in the configuration baseline. The step is complete when the baseline names a supported version and a method your team can rebuild from documentation.
Set up identity and roles through OidcAuth
The identity administrator connects MISP to the organization's OpenID Connect provider using the OidcAuth plugin and maps provider groups to MISP roles. The plugin assigns the first matching role by priority, so the team must order the mappings deliberately and test each role with sample accounts. Remove local accounts that duplicate directory identities, and document who approves role changes. The auditor receives the role mapping configuration, the priority order, the test results and the access review log. Together these show who can view, create and publish intelligence.
Define sharing groups and distribution levels
The information security lead and the threat intelligence owner map the organization's information classification scheme to MISP distribution levels and custom sharing groups. MISP supports sharing down to individual attributes, so the team sets a default level for new events and decides which roles may widen it. Create sharing groups only for recipients the organization has agreed to share with, and record each group's members and purpose. The step closes when the classification mapping and sharing group register are approved. This gives the auditor evidence that disclosure follows documented rules.
Select and document default feeds and taxonomies
The threat intelligence analyst chooses which default feeds, warning lists, taxonomies and MISP galaxies to enable, and records the reason for each choice. Taxonomies and galaxy data are licensed separately from the MISP software, under CC0 1.0 Universal or the 2-clause BSD license, so the team should check those terms before redistributing content. Disable feeds that no one will review, because unreviewed feeds create records without analysis. The output is a feed register listing source, license, owner, enablement date and review frequency.
Configure synchronization with trusted communities
The MISP administrator configures synchronization only with instances and communities whose trust and sharing terms the organization has approved, applying the distribution rules set in the previous step. Test each connection with a limited sharing group before enabling broad pulls, and confirm that outbound events carry the intended distribution level. Keep a record of each connection, its approver and the agreed terms. The auditor can then trace inbound and outbound intelligence to a named agreement and see that sharing used controlled channels.
Enable correlation settings the team will rely on
The detection engineer reviews the correlation engine settings and enables the matching the team will use. Exact matches come first, followed by advanced patterns such as fuzzy hashes and CIDR overlaps once the team has checked the volume of results they produce. Set the granular controls so that correlations respect the sharing boundaries defined earlier. Run a known test indicator through the instance and record the related events it produces. The evidence is a settings export and the test result, which show that analysis links records automatically.
Connect exports to detection tools
The detection engineering team sets up exports or API pulls that send selected intelligence to SIEM, IDS or other detection tools. Supported formats include Suricata, Snort, Zeek, RPZ, STIX, OpenIOC and CSV, and automation can use restSearch or the PyMISP library. Filter each export by distribution level and by the indicator types the receiving tool can act on. Document each export job, its owner and its filters. Verify the connection by confirming that a test indicator reaches the target tool and that the export log records the transfer.
Set a recurring review of feeds and sharing decisions
The threat intelligence owner and the information security lead schedule a recurring review of enabled feeds, synchronization partners, sharing groups and exports. The review interval should follow the organization's own policy, and the team should confirm it with its assessor before the first cycle. Each review compares the current registers with actual use, removes stale sources and records decisions with a named approver. Minutes or a signed register update are the records that show the process operating over time.
Which MISP records serve as audit evidence
An auditor assessing A.5.7 wants to see that threat information was collected from known sources, analyzed, and shared under deliberate controls. The cards below name the MISP records that show each of those steps, along with what the auditor checks in each one.
Event and attribute records
Each event and attribute records the indicator or finding, its source, and its creation and modification timestamps. Auditors sample these to confirm that intelligence was recorded when it arrived and that its origin can be traced. Check that sources are captured in event metadata and that modifications leave a trail. Confirm the exact fields and timestamp behavior in your MISP version before relying on them.
Feed configuration and change history
Feed definitions show which external sources are enabled, how they are pulled, and who configured them. The auditor compares enabled feeds against the sources your threat intelligence process says you rely on, and checks whether changes to feed settings are logged. Confirm which configuration changes your version records in its audit log, and export that evidence on a schedule.
Sharing group and distribution decisions
Distribution levels and sharing groups show who may receive each event or attribute. The auditor checks whether sharing decisions follow a documented policy, for example whether restricted intelligence stays within the organization. Sample events with wider distribution and confirm that someone with the right authority set them. Confirm how your version exposes distribution changes in its logs.
Synchronization and community membership records
Synchronization connections and community memberships show which external MISP instances receive or send intelligence and under what agreement. The auditor asks whether each connection was approved, is still needed, and matches the sharing rules. Keep a register of connected instances with approval records, and confirm in your instance which synchronization and server settings are logged.
Correlation and galaxy outputs used in analysis
Correlation results and galaxy tags show how new intelligence was linked to existing events, threat actors, malware families and MITRE ATT&CK techniques. The auditor uses them to confirm that analysis happened and informed action, not only collection. Retain examples of correlated events with the analyst notes that followed. Confirm how correlation and galaxy data are versioned in your deployment, since they are updated separately from the software.
Role assignments for publishing and viewing
Role definitions and user assignments show who could publish intelligence, who could only view it, and who could administer feeds and sharing. The auditor checks that publishing rights are limited to people with a defined need and that role changes are traceable. If you use single sign-on, confirm how identity provider roles map to MISP roles in your version and retain that mapping as evidence.
How to keep MISP evidence ready for an auditor's sample
Evidence for A.5.7 is only useful if it can be pulled as a sample at any point in the certification cycle, so the first decision is to treat MISP records as a standing evidence stream rather than a bundle assembled before an audit. 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. An auditor may therefore ask for threat intelligence records from any of those years, and the records from month one of the cycle must still be intact and explainable in year three. Confirm with your certification body which periods and sample sizes they expect, and agree the format in advance.
Start with a written procedure for triage and publication. It should state who creates events, who reviews indicators before they leave the instance, what distribution level is the default, when a sharing group is used instead, and what must be recorded when an event is published, withheld or downgraded. Tie the procedure to the wording of Annex A control A.5.7 in your own terms: collect threat information, analyze it, and act on the result. Name the roles in the procedure rather than individuals, and keep a version history so an auditor can see which rules applied on a given date.
Next, make a retention decision for events, attributes, audit logs and user activity. Decide how long events remain in the live instance, when older material is archived or deleted, and who approves any deletion. Set the retention period against your own obligations and the policy your ISMS already holds, not against a default. Then decide where logs of authentication and changes live, because an auditor testing A.5.7 will ask who published what and when. Verify that the chosen settings actually apply on the instance before you rely on them, and record the check.
Periodic exports or snapshots give you evidence that does not depend on the live instance. Schedule exports of events, sharing group definitions, feed configuration and user role assignments, and store them under your own controls, meaning your storage accounts, access rules and backup regime. Record what each export contains, its date, its checksum where you produce one, and who can read it. Test that an export can be restored or read by someone other than the person who made it. Keep the export schedule in the same register as your other ISMS evidence.
Finally, keep a log of review meetings in which feeds, sharing groups and communities were checked. Each entry should list the feeds and communities reviewed, changes made, decisions to add or remove a source, the people present and the follow-up actions with owners. This log is often the strongest single record of the control operating, because it shows that the organization assessed its threat sources rather than accepting defaults. Review the log at least once a year, confirm that every calendar year of the cycle has entries, and ask your certification body whether they want the log in a specific form.
What MISP does not cover for A.5.7
MISP collects, correlates and shares threat data well, but A.5.7 is judged on the whole intelligence process, not the tool alone. The gaps below are the work your organization owns around the platform, and each one is something an auditor is likely to ask about.
Threat analysis and risk decisions
MISP stores indicators, correlates them and flags overlaps, but it does not decide what those findings mean for your business. Your analysts must assess relevance, severity and likely impact, record the reasoning, and link decisions to your risk register. Check that each significant event has a documented analyst assessment outside the raw MISP attributes.
Intelligence process policies and procedures
The documents that define how threat information is collected, analyzed, approved for sharing and retired sit outside MISP. These include the intelligence scope, source selection rules, classification and handling standards, and review cadence. Confirm that each MISP practice you describe in the statement of applicability traces back to a written, approved procedure with a named owner.
Staff competence and defined roles
Auditors commonly ask who triages events, who approves publication, and how analysts are trained on the platform and the taxonomies. MISP can enforce roles, but it cannot prove competence. Maintain role descriptions, training records and access reviews, and confirm that MISP role assignments match the responsibilities written in your procedures.
Incident response and mitigation actions
Intelligence only satisfies A.5.7 when it leads to action. Blocking, hunting, patching and notifying are carried out in your SIEM, firewall, endpoint, ticketing or SOAR tools, not in MISP. Define how an event moves from MISP into those systems, who authorizes the change, and how the outcome is recorded so the chain from intelligence to action can be shown.
Sharing agreements and legal review
Before exchanging data with partners, communities or other organizations, you need agreed terms covering what may be shared, at which distribution level, under which handling rules, and with what legal basis. MISP enforces the distribution settings you choose, but the agreements and their legal review are your responsibility. Confirm each sharing group has a signed agreement before it is connected.
The certification decision
ISO does not certify organizations, and DeployOpen does not issue audit reports or certificates. Only an accredited certification body can grant ISO/IEC 27001 certification after an audit of your ISMS. Use MISP evidence to prepare for that audit, and check the certification body's accreditation through the IAF CertSearch database before engaging it.
Which MISP version and installation method to plan around
Start by fixing the MISP version before any other design work, because it sets the upgrade path, the supported installer and the database choice for the whole build. The MISP project recommends MISP 2.5 for new deployments. MISP 2.4 is end of life and receives security fixes only, and the project strongly advises against installing new 2.4 instances. If your team is considering 2.4 because an older runbook or a colleague's lab used it, treat that as a reason to update the plan, not a reason to build on it. The project also provides an upgrade script for Ubuntu, which matters if you expect to migrate an existing 2.4 instance later.
For most organizations, the installation method follows from the operating system standard already in your data center or cloud account. MISP 2.5 is recommended on Ubuntu 24.04 using the project's provided installer. The project also lists Docker images, Ansible roles, Puppet modules and RPM packages as installation options. Choose the method your platform team can patch, back up and rebuild consistently. An Ansible role or Docker image may suit a team that already manages configuration as code, while a single Ubuntu host built with the provided installer may suit a smaller team. Whichever route you choose, record the exact release, operating system and install method in the system documentation that auditors will read.
Check the database decision before the build. MISP 2.5.47, released on 17 September 2026, introduced a new database migration system with PostgreSQL support. MISP has traditionally run on MySQL or MariaDB with Redis, so you need to confirm whether your standard database platform, backup tooling and DBA skills fit the MISP release you plan to run. Read the 2.5.47 release notes and the upgrade notes for any later release you might adopt. Ask the project or your implementation partner to confirm which database engine the chosen installer configures by default and whether moving between engines after go-live is supported.
Confirm the current release and support window on the MISP download page on the day you plan the build, not from memory or an older document. Release numbers move quickly. MISP 2.5.50 was released on 9 October 2026, so a plan written against 2.5.47 may already be behind. Record the release you confirmed, the date you confirmed it and the end-of-life date the project publishes for it. Those three facts belong in the change record for the build and in the evidence pack that supports your A.5.7 control description.
Decide early who owns the version decision and the upgrade calendar. A version chosen for a pilot can become the production baseline by default, so write the selection into the design record with an owner and a review date. Ask any implementation partner to state in the written scope which MISP release and install method they will deliver, whether they will apply later point releases, and whether the upgrade path to the next minor version is included or priced separately. The project offers paid support services, and a number of third-party providers offer commercial support, so compare those options against your internal capacity before committing.
How much does MISP ISO 27001 A.5.7 work cost and how long does it take?
What drives the cost of MISP work for ISO 27001 A.5.7?
Scope is the main driver. Cost rises with the number of feeds and sharing communities to configure, the number of integrations with SIEM or SOAR tools, and the complexity of single sign-on and role design, since the OidcAuth plugin maps identity provider roles to MISP roles. Hosting choices matter too, including where the instance runs and how much evidence the assessment will need. Teams that already run MISP and understand their management system need less outside effort than teams starting from zero. DeployOpen does not publish a price list. A quote follows from a written scope that lists these items, the deliverables and the timeline, agreed before work starts.
Can DeployOpen certify our organization to ISO 27001?
No. DeployOpen plans, builds and documents the systems and the evidence they produce, so your records can show how MISP supports control A.5.7. ISO does not certify organizations. An accredited certification body decides whether your management system meets the standard, and it audits against its own approach. Before you fix the scope, ask the certification body whether it will accept the evidence pack and how it expects threat intelligence records to be presented. Certification bodies work to ISO/IEC 17021-1 and ISO/IEC 27006-1, and you can confirm an accredited body's status through the IAF CertSearch database.
How long does a MISP A.5.7 implementation take?
Duration depends on scope: how many feeds and communities are connected, how many tools integrate with MISP, how identity and roles are designed, and how much evidence the assessment requires. No duration is supplied for this work, so the timeline is stated in the written scope and agreed before work starts. Ask for milestones that separate the build, integration testing, staff training on sharing rules and evidence collection. Your internal calendar also sets the pace, because reviews by named owners and sign-off on sharing groups and classification can take longer than the technical build itself.
What does our team need to provide for the engagement?
Name owners early: a project sponsor, a technical owner for the MISP instance, an ISMS owner who knows control A.5.7, and a person who can approve sharing groups and information classification. Provide access to the environment, including hosting, the identity provider, the SIEM or SOAR tools in scope, and test accounts. Decide which information may be shared with which communities and how sensitive attributes are classified. Staff also need time for reviews of configuration, workflows and evidence. Keep a decision log from kickoff, because open decisions are the most common reason a schedule moves.
Can our own team run MISP for ISO 27001 A.5.7 alone?
Yes, if you document the procedure and assign an internal owner. Your team can install the platform, configure feeds, communities and correlation, and record how threat intelligence feeds your risk process. The trade-off is effort and expertise. Designing the sharing model, configuring role mapping and writing evidence that an auditor will accept takes time and experience that staff may not have on hand. Operations also need upgrades on schedule: MISP 2.4 is end of life with security fixes only, and MISP 2.5 is the recommended version for new deployments. Many teams split the work, with an outside partner building the baseline and their own staff running it.
Is the cost a one-time payment or does it recur?
Build work is one-time. It covers scoping, installation, integrations, single sign-on, sharing design and the first evidence set. Recurring costs include operating the platform, maintaining feeds and communities, applying upgrades, reviewing sharing groups periodically and refreshing evidence for each assessment. ISO/IEC 17021-1 sets a three-year certification cycle with at least one audit in each calendar year, according to European Accreditation's FAQs, so plan for evidence to stay current across that period. Ongoing support, upgrades and continuous testing are available as retainers, which you can compare against the written scope.
What should a quote for this work include?
A quote should follow from a written scope that names deliverables, exclusions, client responsibilities and acceptance criteria. Ask for the list of feeds, communities and integrations in scope, the number of single sign-on roles and how they map to MISP roles, the hosting assumptions, the contents of the evidence pack and the review cycle. Confirm which items DeployOpen delivers and which your team owns. Ask for timeline milestones and the process for handling scope changes. Most engagements are fixed-scope, so any change should be written into a revised scope before the extra work begins.
How DeployOpen scopes and delivers A.5.7 configuration and evidence
DeployOpen plans, implements, documents and supports self-hosted MISP inside your own infrastructure, so the threat intelligence records behind A.5.7 are produced and kept where your team controls them. Engagements are fixed-scope, with the scope, deliverables and timelines agreed in writing before work starts.
How we scope
- The written scope names the feeds, sharing communities and internal sources that will feed your MISP instance.
- It defines which MISP outputs count as A.5.7 evidence, such as event records, feed logs and correlation results.
- It states who reviews intelligence, how often, and which roles can publish or share events.
How we build
- We install MISP in your environment using a supported method, with the version chosen against current project guidance.
- We configure distribution levels, sharing groups, taxonomies and galaxies to match your information classification rules.
- We set up authentication, such as OIDC single sign-on through the OidcAuth plugin, and test role mapping before go-live.
How we hand over
- You receive documentation of the configuration, feed and sharing settings, and the procedures that produce threat intelligence records.
- We provide a control evidence map that links A.5.7 to the MISP events, logs and review records your auditor will request.
- Handover includes a walkthrough with your security team on running reviews and exporting evidence.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer after handover.
- Upgrades are planned around the MISP release line, including the move off 2.4 and any database migration steps for your version.
- Backups and restore tests of the MISP database and configuration are scoped with your operations team.
