Does OpenCTI help meet ISO 27001 threat intelligence requirements?
If you own the ISMS and are preparing for certification, you need evidence that threat intelligence is collected, analyzed and acted on as Annex A control A.5.7 requires. OpenCTI can host, structure and evidence that work, including the reports, indicators, relationships and ATT&CK mappings your analysts produce. The control itself, however, is an organizational process that people run: they decide what to monitor, who analyzes it, how findings reach decision-makers and what changes as a result. The platform records the outputs of that process. It does not perform the process for you, and an auditor will look at the people and decisions behind the records.
Across the related requirements, the platform touches some areas and not others. For clause 6.1.2, threat reports and indicators can inform the inputs to your risk assessment, but the risk method, criteria and treatment decisions stay in your risk governance. For A.8.16, OpenCTI does not monitor systems or network activity. It holds indicators that detection tools can consume through connectors, so the monitoring evidence usually sits in your SIEM or monitoring platform. For A.8.8, CVE-linked intelligence can support prioritization, while scan results and patch records come from your vulnerability tools. For A.5.6, the platform can record groups and shared material, but membership and participation are organizational decisions.
OpenCTI does not supply your ISMS scope, your intelligence requirements, analyst competence records, management review or the statement of applicability. Those remain your documents. DeployOpen plans, implements and documents the platform inside your infrastructure and prepares evidence for assessment, but it does not issue audit reports, attestations or certifications. ISO does not certify organizations. Accredited certification bodies do, working to ISO/IEC 17021-1 and ISO/IEC 27006-1, and they decide whether your evidence is sufficient for the control.
Before deployment, decide which requirements the platform will evidence and who owns each record. Confirm whether you need Enterprise Edition features such as priority intelligence requirements or audit logs, since the Enterprise Edition uses a proprietary license separate from the Apache 2.0 Community Edition. Then ask your certification body how it will sample evidence for A.5.7 and how the three-year certification cycle applies to your organization. Their answers should shape which records the platform must keep, how long, and in what form.
Mapping A.5.7 and related requirements to OpenCTI capabilities
This table maps A.5.7 and four related ISO/IEC 27001 requirements to what OpenCTI provides and the configuration each one needs. Read the middle column as platform capability and the third column as work your team must do, and treat rows marked as input only as sources of evidence, not proof of conformity. The main takeaway is that OpenCTI supports collection and analysis records well, while risk, vulnerability and monitoring decisions stay in your own processes.
| Requirement | What the platform provides | Configuration needed |
|---|---|---|
| A.5.7 collection and analysis | Stores threats, indicators and reports in a STIX2-based schema, with connectors that import feeds. Analysis is performed by analysts; the platform holds the output. | Enable import connectors for approved sources. Define who reviews feeds and how analyst reports are created and approved. |
| Clause 6.1.2 risk assessment inputs (input only) | Input only. Records threat actors, campaigns and ATT&CK techniques that can inform your risk criteria. It does not perform the risk assessment. | Load the MITRE ATT&CK connector. Map relevant threats to your risk register and review them on a set schedule. |
| A.5.6 contact with special interest groups (input only) | Input only. Can receive shared intelligence through the MISP integration. The platform does not manage membership or exchanges with external groups. | Confirm the MISP integration and sharing rules. Agree handling markings and who may import or publish shared material. |
| A.8.8 technical vulnerabilities (input only) | Input only. Can hold vulnerability-related objects and link them to threats and ATT&CK techniques. Patching and remediation stay in your vulnerability process. | Confirm with the vendor which vulnerability object types your version supports. Import vulnerability feeds through approved connectors. |
| A.8.16 monitoring activities (input only) | Input only. Holds indicators that detection teams can use. Detection and alerting run in your monitoring or SIEM tools. | Export or stream indicators to your monitoring tools through connectors. Set expiry and review rules for indicators. |
| Evidence trail across clauses | Enterprise Edition adds audit logs and priority intelligence requirements. These show what was collected and why. Auditors decide whether this is sufficient. | Confirm Enterprise Edition licensing. Document the intelligence requirements and retain audit log exports under your retention policy. |
How strategic, tactical and operational intelligence fit inside OpenCTI
This section maps the three levels of threat intelligence described in ISO/IEC 27002:2022 to the objects that OpenCTI stores, so that an auditor can follow a line from the business view of the threat environment down to the technical detail of an attack. The strategic level covers the changing threat landscape: which threat actors and campaigns matter to the organization, and why. In OpenCTI, this work is usually held in reports and campaigns. A report packages an assessment with its author, its publication date and the objects it discusses, while a campaign groups related activity over a period. Confirm who writes these reports, who approves them, and what a finished strategic assessment looks like in your organization before you configure the templates.
The tactical level describes how adversaries operate. In OpenCTI, intrusion sets represent the groups or actors behind activity, and ATT&CK techniques describe the methods they use. The MITRE ATT&CK connector is the usual route for loading techniques into the knowledge schema, and linking an intrusion set to the techniques it uses gives analysts a view they can compare with detection coverage. Confirm which ATT&CK version your connector loads, how often it refreshes, and who checks that the mappings reflect your own reporting. Mapping is only as current as the source data, so schedule a review rather than assuming the links remain accurate.
The operational level covers the specific indicators and observables that support detection and blocking, such as IP addresses, domain names and file hashes. In the STIX2-based schema, an indicator carries a detection pattern and an observable records what was seen in a specific place. Operational data changes quickly, so the important decisions are how long an indicator stays valid, when it is revoked, and who approves its removal from blocklists. Set those rules before bulk imports begin.
OpenCTI records and links these objects, and the relationships between them are stored as STIX relationships. The platform does not decide what an object means. Analysts decide whether an indicator is still relevant, how much confidence to place in a source, and whether a campaign affects the organization, and management decides what action follows. For ISO/IEC 27001 A.5.7 evidence, document those roles, the review steps and the dates on which decisions were made, because the graph shows the links but the assessment records the judgment behind them.
What evidence OpenCTI produces for an ISO 27001 audit
Auditors reviewing A.5.7 look for records showing that threat intelligence was requested, analyzed, communicated and acted on. The six items below are evidence OpenCTI can produce, with guidance on how to keep each one. No single item satisfies the control alone, so pair them with your risk assessment records and management review minutes.
Intelligence requirements and their status
Each requirement records what the organization needs to know, who owns it, and its status at each review. In OpenCTI, priority intelligence requirements are an Enterprise Edition feature, so confirm your license covers them before relying on them as evidence. Export the requirement list with owners and review dates at every review cycle, and store dated copies with your management review records. Check that each requirement links to the reports or indicators it produced.
Published reports with dates and authors
Published reports are the main record that intelligence was analyzed and communicated to its intended audience. Check that each report carries a publication date, an author, an intended audience and links to the objects it references. Keep an export of the report index and the report documents themselves, filed alongside the decisions they informed. Confirm how authorship is recorded when a service account publishes on behalf of an analyst.
ATT&CK-linked objects
Threat actors, campaigns, malware and indicators can be linked to MITRE ATT&CK techniques through the ATT&CK connector. These links show that analysis reached tactical and technical detail, which is the level ISO/IEC 27002 describes for threat intelligence. Confirm which ATT&CK version the connector imported and that analysts reviewed the mappings instead of accepting imports unchecked. Keep a relationship export for each review period so the mappings can be reproduced later.
Connector and feed configuration
The configuration record shows which external sources feed the platform, including import connectors and any MISP or TAXII feeds, along with their schedules, owners and filters. Auditors look for evidence that sources were chosen deliberately and reviewed on a set cycle. Export connector definitions from your configuration management system and log every change with a ticket. Confirm that API tokens and feed credentials are held in a secrets store and are absent from the exported files.
Access and activity records
These records show who can read, edit and publish intelligence and what they did with that access. Audit logs and activity monitoring are an Enterprise Edition feature, so confirm whether your license includes them. Without them, export user, group and role assignments on a fixed schedule and retain identity provider sign-in logs for the period your ISMS defines. Ask your auditor which sampling period they will use before setting retention.
Platform version records
Version records show which OpenCTI build ran in each period and which LTS line it belonged to. Regular releases use the form x.YYMMDD.z and LTS releases use x.YYMMDD.z-lts.n, so the version string itself carries the build date. Record each upgrade in a change record with the release notes reviewed and the date applied. Snapshot the deployment manifest before every upgrade so the earlier configuration can be shown if an auditor asks.
What auditors ask about threat intelligence during a certification cycle
Auditors do not assess A.5.7 once. Under ISO/IEC 17021-1, an accredited certification cycle for a management system lasts three years, and the certification body must carry out at least one audit in every calendar year, either a surveillance audit or the recertification audit. Your threat intelligence evidence therefore has to accumulate over the cycle. An auditor in the second or third year will expect to see what changed since the last visit, how intelligence requirements were revisited, and what happened to the findings. Before the first audit, ask your certification body for its audit calendar and plan evidence capture around it, so that each audit window has a dated record of activity rather than a single summary prepared at the end.
The questions usually follow the logic of A.5.7 itself. Auditors ask how intelligence requirements were set at strategic, tactical and operational levels, who approved them, and how often they are reviewed. They ask which sources feed the program, how information was analyzed, and how the output reached risk assessment under clause 6.1.2 and the related work on technical vulnerabilities (A.8.8) and monitoring (A.8.16). In OpenCTI, the evidence for these questions is usually the requirement records, dated reports linked to the relevant ATT&CK techniques, connector ingestion history and, where your edition includes it, the activity and audit logs. Confirm with your certification body which of these formats it will sample.
The edition and amendment history matters only where it changes the documentation an auditor reads. IAF MD 26:2023 required certifications to ISO/IEC 27001:2013 to expire or be withdrawn by 31 October 2025, so your statement of applicability, control references and procedures should map to the 2022 edition and its 93 Annex A controls. The climate action amendment published on 23 February 2024 affects clauses 4.1 and 4.2 rather than the control set: you must record whether climate change is a relevant issue and whether interested parties have climate-related requirements. Accredited bodies apply ISO/IEC 27006-1:2024 under IAF MD 29:2024, with a 31 March 2026 deadline, so confirm with your body which version applies to your audit dates.
Your certification body conducts each audit and makes the certification decision. DeployOpen does not issue audit reports, attestations or certificates. Our role is to prepare the platform, the controls and the evidence set that the body will examine, which includes configuring OpenCTI, documenting the intelligence procedures and setting up repeatable exports of records. Plan platform currency as part of that evidence. OpenCTI LTS lines are each supported for one year, and LTS releases require a specific license key, so an upgrade calendar should keep the version in production within its support window during every audit year. Ask your auditor which samples they will request so you can prepare them in advance.
What OpenCTI does not cover for A.5.7
OpenCTI stores and connects threat data, but several parts of A.5.7 are organizational work. The cards below name the gaps that need another owner, process or license, and what to confirm with Filigran and your auditor before you rely on the platform as evidence.
Intelligence process and management review
A.5.7 expects the organization to collect and analyze threat information, but it does not define the process around OpenCTI. Someone must set the intelligence cycle, name the roles that produce and approve outputs, decide how often threat information is reviewed and record management review of the results. OpenCTI can store reports and tasks, but the policy, procedures and meeting records sit in your management system. Ask your auditor which records they expect for each of these steps.
Analyst judgment on threat assessments
OpenCTI can enrich indicators, map observables to ATT&CK techniques and show relationships between actors, campaigns and targets. It does not decide whether a threat is relevant to your business, how likely it is, or what it means for your risk register. Those assessments need named analysts, documented reasoning and a link to the clause 6.1.2 risk assessment. Confirm with your auditor how they want assessment rationale recorded, and whether free-text notes in the platform are enough.
Special interest group membership (A.5.6)
A.5.6 covers contact with special interest groups, such as sector information-sharing communities and vendor user groups. OpenCTI does not join those groups or pass on their advisories. Membership, the people who attend, and how shared intelligence is brought into OpenCTI are organizational decisions. If you plan to share through a community or feed, confirm with Filigran which sharing options your edition supports, and record the agreements that govern them.
Vulnerability and monitoring controls
A.8.8 covers management of technical vulnerabilities, and A.8.16 covers monitoring activities. OpenCTI can hold vulnerability and threat records, but it does not scan assets, track patch status or watch your systems for anomalous behavior. Those controls need a vulnerability scanner, a patch process and a monitoring stack such as a SIEM or log platform. Ask your auditor to trace each threat report to the tool that checks your exposure, and confirm which tool holds the evidence for A.8.8 and A.8.16.
Enterprise Edition features need a license
Several capabilities auditors often ask about are Enterprise Edition features, not Community Edition features. These include activity monitoring and audit logs, playbooks, priority intelligence requirements, SSO configuration and AI features. Since OpenCTI 7.260224.0, defining and using authentication strategies, including SSO, requires the Enterprise Edition. Confirm license terms, trial and free options with Filigran, and check with your auditor whether audit logs and requirement records must come from the licensed edition.
How to configure OpenCTI for A.5.7 evidence
Eight steps take you from scope and licensing to a working OpenCTI deployment that produces traceable threat intelligence evidence for A.5.7. Steps 2, 4, 6 and 7 touch features that depend on the Enterprise Edition, so confirm licensing before you design them.
Define the ISMS scope and requirements
The information security lead, with the risk owner and business leads, writes a short scope statement for the ISMS and the threat intelligence it must support. List the intelligence requirements at strategic, tactical and operational levels, such as threat trends for leadership, adversary behavior for security operations and indicators for detection teams. Link each requirement to a risk in your clause 6.1.2 risk assessment so the reason for collecting it is traceable. Done when the scope and requirement list are approved and stored under document control.
Choose the edition and confirm licensing
The platform owner compares Community Edition, licensed under Apache License 2.0, with Enterprise Edition, licensed under the proprietary OpenCTI Enterprise Edition License. Check the features your requirements need, such as priority intelligence requirements, audit logs, organization-based data segregation and SSO, against the Enterprise feature list. Confirm with Filigran which license your use requires. If you plan to run LTS releases, confirm that you hold the LTS license key before deployment, because LTS builds require one. Done when a licensing decision record names the edition, the license terms and the key holder.
Deploy the platform and dependencies
The platform engineer deploys OpenCTI and its dependencies in infrastructure you control: Elasticsearch 8.0 or later or OpenSearch 2.9 or later, Redis 7.1 or later, RabbitMQ 3.11 or later, and S3-compatible storage such as MinIO. Follow the documented sizing, which starts at 2 cores and 8 GB RAM for the platform and 2 cores, 8 GB RAM and 16 GB SSD for the search backend, and plan at least one platform node for every 3 workers. Treat these as minimums and test them against your expected volume of reports and indicators. Done when all services report healthy, the UI loads and a test import completes end to end.
Configure authentication and role-based access
The identity administrator connects OpenCTI to your identity provider and defines roles. OpenCTI supports local users and LDAP, plus SAML, OpenID Connect and other strategies. Since 7.260224.0, defining and using authentication strategies, including SSO, is an Enterprise Edition feature, so confirm which options your edition allows before you design the login flow. Map analysts, report authors and reviewers to separate roles, limit write access to people who publish reports, and remove default or shared accounts. Done when a test user from each role signs in and can reach only the content that role requires.
Enable the ATT&CK connector and feeds
The threat intelligence analyst enables the MITRE ATT&CK connector, which brings the framework into OpenCTI so reports and indicators can be mapped to techniques. Add further feeds, such as MISP or TheHive integrations or other connectors from the connectors repository, only where they support a stated requirement. Set the import scope, confidence and labeling rules first so every imported object has a source and a date. Done when a sample import is reviewed, ATT&CK techniques appear linked to a test report, and the connector logs show no unresolved errors.
Set up report templates and requirement tracking
The threat intelligence lead builds report templates for the three levels: a strategic summary for leadership, tactical notes on adversary behavior mapped to ATT&CK, and operational items with indicators and actions. Create a requirement register that links each intelligence requirement to its owner, the report that answers it and the controls it supports, including A.5.7, clause 6.1.2, A.5.6, A.8.8 and A.8.16. Priority intelligence requirements are an Enterprise Edition feature, so if you use Community Edition, keep the register in a controlled document outside the platform. Done when every requirement has an owner and at least one linked report.
Define evidence capture and retention
The compliance lead defines what counts as evidence and where it is kept. Typical items include approved reports, the requirement register, review minutes, connector configuration records and audit logs. Activity monitoring and audit logs are Enterprise Edition features, so confirm which records you can produce on your edition. Set a retention period in line with your records policy and confirm it with your certification body, which decides what records it will sample. Store evidence in access-controlled, backed-up storage with an index. Done when a sample evidence pack for one review cycle can be produced and traced back to a requirement.
Schedule reviews and version upgrades
The platform owner schedules periodic reviews of requirements, feeds and access, and sets the upgrade cadence. LTS releases arrive every 6 months, each is supported for 1 year, and consecutive LTS versions overlap by 6 months. Non-LTS releases ship from daily to weekly, so many teams choose to follow an LTS line for stability. Test each upgrade in a staging copy, apply it, record the change and confirm that the evidence pack still reads correctly. After stabilization, LTS releases receive only critical bug and security fixes. Done when the review calendar and upgrade runbook are approved and the first review is recorded.
What does an OpenCTI ISO 27001 A.5.7 setup cost and how long does it take?
What drives the cost of an OpenCTI ISO 27001 A.5.7 setup?
The main cost drivers are scope, the number of feeds and connectors, sizing, identity and access design, and how much ISMS documentation already exists. Two cost types apply. Services are a one-time fee for planning, build, documentation and handover, quoted from the written scope. Infrastructure and software are mostly recurring: hosting in your accounts or data centers, and any OpenCTI Enterprise Edition license, which is licensed by Filigran under a proprietary license, not by DeployOpen. Ask Filigran directly for current Enterprise Edition terms, including whether your required features are included and how renewals work. Ask your partner to separate services, infrastructure and licensing in the quote so you can see what recurs and who is paid for each part.
How long does an OpenCTI threat intelligence implementation take?
Timelines depend on scope: how many intelligence sources you ingest, how many connectors you run, how many teams and roles need access, whether single sign-on is included, and whether your infrastructure is ready. Each engagement is fixed-scope, so the exact duration, milestones and dependencies are agreed in writing before work starts. Ask for a milestone plan that names the points where your team must act, such as providing identity provider details, approving intelligence requirements or granting infrastructure access. Delays usually come from waiting on those inputs rather than from the build itself, so the plan should show who owns each dependency and the date by which it is needed.
Can our internal team set up OpenCTI for A.5.7 without a partner?
Yes, an internal team can set up OpenCTI, provided it has the skills and capacity to run the work to an audit-ready standard. The platform depends on Elasticsearch or OpenSearch, Redis, RabbitMQ and S3-compatible storage, so the team needs Linux administration, container and orchestration experience, and operational knowledge of those services. It also needs identity integration skills, familiarity with STIX2 and MITRE ATT&CK mapping, and someone who can write intelligence requirements and link them to the ISMS. Consider whether the people with these skills can also run monitoring, backups and upgrades after go-live, because those tasks recur for as long as the platform runs.
What does our organization need to provide for an OpenCTI engagement?
Three groups of inputs matter most. First, named intelligence requirement owners who can state which threats, sectors and assets the organization must track, and who will review outputs at the strategic, tactical and operational levels. Second, infrastructure access: accounts or data center capacity, network paths, DNS, certificates, storage, and an identity provider the platform can integrate with. Third, sign-off from the ISMS owner on the scope, the control mapping for A.5.7 and the evidence the platform will produce. Also name a technical owner who can approve changes during the build. Confirm these responsibilities in the written scope so that delays in client inputs are visible and handled through agreed change control.
Does OpenCTI need Enterprise Edition for SSO and access control?
Authentication strategies, including SSO, have been an Enterprise Edition feature since OpenCTI 7.260224.0, so single sign-on configuration requires that license. The Enterprise Edition also adds activity monitoring and audit logs, organization-based data segregation, authorized members, playbooks, full-text document indexing, AI features and priority intelligence requirements. Each of these may matter for an A.5.7 setup, depending on how you segregate data and prove who accessed intelligence. Long-term support releases also require a specific LTS license key. Before the design phase, map each requirement to a feature, confirm the license scope with Filigran, and record the result in the written scope so the quote and the design reflect the same assumptions.
What sizing does OpenCTI need before the build starts?
OpenCTI's documented minimums are 2 cores and at least 8 GB RAM for the platform, and 2 cores, 8 GB RAM and 16 GB SSD for Elasticsearch or OpenSearch. The deployment documentation also recommends at least one platform node for every 3 workers. These are starting points, not a sizing for your organization. Actual requirements depend on how many feeds and connectors run, how much data they produce, how long you retain it, how many users query the platform, and whether you add enrichment. Ask the implementation partner to state its sizing assumptions in the quote and to test them against a realistic import load before go-live, and ask for the results in writing.
Will DeployOpen help us pass the ISO 27001 audit for A.5.7?
DeployOpen can prepare the systems, controls and evidence that support A.5.7, including documented intelligence requirements, the OpenCTI configuration, access records and how threat intelligence feeds into risk assessment under clause 6.1.2 and related controls. DeployOpen does not issue audit reports, attestations or certifications. Independent auditors assess the ISMS, and accredited certification bodies issue certificates. Ask your partner to show how each piece of evidence maps to A.5.7 and to related controls, and ask your certification body which evidence it expects to sample. Agree the evidence list in writing before the build so the platform is designed to produce it.
What should we ask for in a written OpenCTI quote?
Ask for a quote that ties every price to a written scope. The scope should list the A.5.7 deliverables, the number of feeds and connectors, environments, sizing assumptions, identity integration, and the integrations with other tools. Ask which costs are one-time and which recur, and who pays for infrastructure and each Enterprise Edition license. Request a milestone plan with client dependencies, a handover that includes documentation and training, and the support terms that follow go-live. Also ask how change requests are priced, what is excluded, and how upgrades to new OpenCTI releases and LTS lines are handled. Compare quotes on the same scope, not on the lowest headline figure.
How DeployOpen scopes and supports OpenCTI compliance work
DeployOpen plans, implements, documents and supports self-hosted OpenCTI inside your own infrastructure, so threat intelligence records for A.5.7 stay under your control. Engagements begin with a written scope that defines which intelligence sources, reports and ATT&CK mappings the evidence will cover. DeployOpen prepares the systems and evidence, while your certification body makes the assessment.
How we scope
- Written scope lists the intelligence levels, reports and ATT&CK mappings that will be evidenced for A.5.7.
- Scope names the intelligence requirements, consumers and review cadence your threat process must support.
- Engagements are fixed-scope, with deliverables and timelines agreed in writing before work starts.
How we build
- Deploy the OpenCTI platform, workers, RabbitMQ, Redis, and search and storage services in your infrastructure.
- Configure connectors for your feeds and map ingested reports to ATT&CK techniques for analysts to review.
- Set access controls and confirm which SSO, audit log and segregation features need the Enterprise Edition license.
How we hand over
- Written records of intelligence requirements, collection sources, analysis steps and dissemination rules for the control.
- Runbooks for daily operations, backups, connector health checks and OpenCTI upgrade steps.
- Evidence packs showing how outputs feed risk assessment under clause 6.1.2 and monitoring under A.8.16.
How we support
- Retainers cover ongoing support, upgrades and continuous testing, agreed separately from the initial build.
- Upgrades follow OpenCTI's LTS and regular release lines, with changes planned and tested before rollout.
- Ask your certification body to confirm the evidence meets its requirements; DeployOpen does not issue audit reports.
