Do you need OpenCTI audit logs and data segregation for a shared team?
Activity monitoring, audit logs, organization segregation and authorized members are Enterprise Edition features, licensed under the proprietary OpenCTI Enterprise Edition License. They are not part of the Community Edition, which is licensed under the Apache License 2.0. If your threat intelligence team shares one OpenCTI instance across internal groups, customers or regulated business units, this is the first decision to make, because it determines which edition you deploy before any design work begins. A team of one trusted group of analysts may manage well without these controls, but shared access across boundaries usually changes the requirement.
Each capability answers a different question. Activity monitoring and audit logs record who acted on the platform and when, which supports investigating a disputed change to an indicator, reviewing the access history of a departing analyst, or showing an assessor how changes to intelligence are recorded. Organization-based data segregation controls what a user can see, keeping one customer's or business unit's objects, sightings and reports apart from another's. Authorized members determine which accounts can work within a given organization's data. These controls interact with your identity setup, so the mapping of users and groups to organizations should be drafted together with your authentication strategy.
The exact behavior must be checked in the Enterprise Edition documentation for the release you run, because event coverage, retention and export options can change between releases. Confirm which actions are logged, how long log entries are kept, whether logs can be forwarded to your SIEM or retained in your own storage, and how segregation applies to shared relationships, files and full-text indexed documents. Also confirm how authorized members are granted and removed, and whether administrators can see data across all organizations. Put these questions to Filigran in writing before a design depends on any answer.
Turn the answers into decisions and a test. Decide who may read audit records, whether that access fits your internal retention and access policy, and whether any customer contract prohibits mixing data in one instance. Then run a proof of concept on a trial license, which Filigran offers, using two test organizations and two test users. Confirm that one user cannot see the other organization's objects, and that a sample change appears in the audit log with the expected detail. Licensing is a recurring cost quoted by Filigran, and the test results should feed directly into that quote and the scope you agree with any implementation partner.
Which OpenCTI Enterprise Edition control fits which need
This table compares the four controls for audit logs and data segregation: activity monitoring, organization-based segregation, authorized members, and the Community Edition baseline. Read each row by the question your team must answer first. The Enterprise Edition license is required for the first three controls, and Filigran offers it on premises or as SaaS, with trial licenses available to test before you commit.
| Capability | What it is for | When it fits | What to confirm with Filigran or in the docs |
|---|---|---|---|
| Activity monitoring and audit logs | Records user activity on the platform so administrators can review who did what. | Fits teams that must show a reviewable trail of activity for internal review, incident reviews or assessors. | Which events are captured, how long they are kept, and how logs can be exported to your monitoring tools. |
| Organization-based data segregation | Limits what each organization can see within one shared OpenCTI instance. | Fits shared deployments where several teams, partners or customers need different data boundaries. | How segregation applies to entities, relationships and connector-imported data, and whether it matches your sharing model. |
| Authorized members | Restricts which accounts can access the platform and what they can do in it. | Fits deployments handling sensitive or regulated intelligence where access must be limited to vetted people. | How membership is granted and revoked, and how it works with your identity provider and SSO configuration. |
| Community Edition baseline | Provides core threat intelligence management under the Apache License 2.0 without the Enterprise controls. | Fits single-team use, evaluation or research where no shared-tenancy or audit requirement applies. | Which of your requirements the Community Edition cannot meet, and whether a documented compensating control is acceptable to your assessor. |
When a shared or regulated OpenCTI deployment needs these controls
A team should move from a single-group Community Edition setup to Enterprise Edition controls when its obligations change, not when its platform gets bigger. The first trigger is sharing: several internal groups, business units or external parties using the same OpenCTI instance and needing to see different intelligence. The Enterprise Edition adds organization-based data segregation and authorized members, which are the features that let one deployment hold data for several parties without giving each of them everything. If every user already sees the same data and no outside party has access, the Community Edition may still meet the need.
The second trigger is data that must be separated by sensitivity or ownership. Examples include intelligence received under a sharing agreement that limits who may read it, reporting from a regulated business line that must stay within that line, or partner-supplied data that the originating party controls. Before buying a license, the team should write down which data classes exist, who owns each one, and who may read or change it. Those rules then become the test cases for segregation and authorized members in a pilot. Do not assume that a folder or label convention will enforce the same rules.
The third trigger is evidence. Activity monitoring and audit logs in the Enterprise Edition record activity so that the team can answer who viewed or changed a piece of intelligence and when. Ask internal audit, compliance and legal what questions they expect to answer, how far back the records must go, and who will review them. Check whether the log output can be retained, exported and protected in your own logging stack, and confirm the retention period with the vendor because it is not set out in the facts used for this page. If your obligations require evidence of access and change, plan for this from the start, since historical activity cannot be reconstructed later.
The fourth trigger is governance review. Shared intelligence programs often need periodic access reviews, named owners for each organization or data group, and a documented process for adding or removing members. Authorized members give the team a way to control who has access, but someone still has to run the review, approve changes and keep records of the decisions. Decide who owns that process before go-live.
Single sign-on is a separate decision that appears in the same Enterprise Edition feature set. Since OpenCTI 7.260224.0, defining and using authentication strategies, including SSO, requires the Enterprise Edition. A team may need SSO for identity reasons even if it does not need segregation or audit logs, and the reverse is also true. Map each requirement to a specific feature, record the obligation behind it, and confirm the features and license terms with Filigran before you purchase, because the license requirement is the reason to make this decision on paper first.
How to set up audit logs and segregation in a new deployment
This sequence takes a new OpenCTI Enterprise Edition deployment from license confirmation to documented evidence that activity is logged and that organizations are segregated as designed. Each step closes with a check, so a gap found early is fixed before the platform holds shared or regulated data.
Confirm the license and Enterprise Edition release
The platform owner confirms that the deployment will run the OpenCTI Enterprise Edition, which is licensed under the proprietary OpenCTI Enterprise Edition License, and records the exact release string. Regular releases use the x.YYMMDD.z format. LTS releases use x.YYMMDD.z-lts.n and require a specific LTS license key, so confirm the key with Filigran against the LTS line before installation. Check: the license is valid for Enterprise features and the planned release tag matches the license.
Deploy the platform and its dependencies
The infrastructure team deploys the platform, Python workers and connectors following the OpenCTI deployment overview. Dependencies are 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. Size the platform nodes using the documented guidance, which recommends at least one platform node for every 3 workers. Check: each dependency reports a supported version, the web interface loads, and a test import sent through RabbitMQ is processed by a worker.
Define the organization model and authorized members
The platform administrator writes down the groups that own or consume data, then creates an organization for each group in the platform. Assign authorized members to each organization from the group list approved by the data owners. If single sign-on is used, confirm the identity provider groups map to the intended organizations, since defining authentication strategies is an Enterprise Edition feature. Check: each organization lists exactly the intended members, and no account belongs to a group it should not access.
Configure activity monitoring and audit log access
The administrator enables activity monitoring and audit logs in the Enterprise Edition settings and restricts who can read them to the security or compliance reviewers named in the plan. Confirm log retention with your own policy and with Filigran, since this guide does not set a retention period. Make one harmless administrative change and check that it appears in the audit log. Check: the change is recorded with the acting user and time, and a non-reviewer account cannot open the log views.
Test segregation with accounts from each group
Create one test account for each organization and one account that belongs to no organization. Sign in with each account and attempt to view, search and edit known objects owned by other organizations. Record the expected result before each attempt. Illustrative example: a test account in one organization should not see a report owned only by another organization. Check: every attempt matches its expected result, and any mismatch is logged as a blocking defect until it is fixed and retested.
Review the logs for the test activity
The reviewer filters the audit logs by each test account and matches every login, read, edit and denied action from the previous step to a log entry. Confirm that each entry shows the user, time and object involved. Confirm that the reviewer's own access to the logs is limited to the authorized reviewer role. Check: every test action has a matching log entry, and any missing entry is treated as a failed control that must be investigated before sign-off.
Document the results as evidence
The platform owner writes a test record that includes the release string, the LTS key identifier (never the key itself), dependency versions, the organization model, the member list, each test case with its expected and actual result, and the log extracts that prove the activity. A second engineer should be able to repeat the test from the record alone. DeployOpen can prepare this evidence for a compliance assessment, but independent auditors and certification bodies make the assessment decision. Check: the record is signed off by the data owner and the security lead.
How organization segregation and authorized members divide the data
Organization-based segregation is the Enterprise Edition control that decides which groups of users and integrations can see which data in the platform. Its purpose is to let one OpenCTI instance hold material for several teams, partner groups or business units without every user seeing everything. Authorized members are the people and accounts assigned to each organization, and their membership determines what they can read and what they can change. Design this before any data is loaded. Once reports, indicators and observables from several sources sit in one knowledge graph, separating them later means auditing relationships, shares and imports that were never tagged for a boundary. Decide the organization list, the membership rules and the default owner for imported material first.
The access rules operate on the knowledge schema, which is based on the STIX2 standards, and on everything that reaches it through the web application and the GraphQL API. Test the model through the API as well as the UI. A rule that hides an object in the interface may still leave it reachable through a query if the rule is not enforced on every path. Ask how object-level restrictions apply to relationships between objects in different organizations, because a relationship can reveal that an entity exists even when its content is hidden. Confirm the answer in the Enterprise Edition documentation before you commit to a design, and record it with the date you checked.
Connectors and Python workers also write data. Workers consume RabbitMQ messages for asynchronous writes, and import, enrichment, file extraction, export and stream connectors all create or modify objects. Each of these runs under an account with its own organization membership. If that account belongs to a broad organization, a connector can push data into a group that should not receive it, or an enrichment step can attach material across a boundary. Give every connector an explicit organization assignment, a named owner and a written reason for its scope. Include integration accounts in the access review alongside human users, since they often hold the widest write permissions.
Shared objects need an explicit list. Some objects, such as marking definitions or reference data, may need to be visible across organizations, while others must stay inside one. Before rollout, check the Enterprise Edition documentation or ask Filigran which object types are segregated, which are shared, and how an object's organization is set on creation and on update. Record the answer in your data model document. Then test with a non-production dataset: create accounts in two organizations, run a sample connector import, and confirm that each account sees only its scope through both the UI and the GraphQL API. Illustrative check: an account in a partner organization should receive an access error when it queries a restricted report by identifier.
Security and operational risks to plan for
Enterprise Edition adds activity monitoring, audit logs and organization-based segregation, but these controls are only as strong as the accounts, infrastructure and change processes around them. The cards below cover the risks to review before a shared or regulated deployment goes live. Each one names a control to decide on and a check to run.
Who can read and change audit logs
Audit logs record activity, so their own access controls matter. Confirm which roles can view audit records, whether any role can edit or delete them, and whether a platform administrator can change logging settings. Restrict audit log access to a small named group outside day-to-day platform administration, then test that a standard administrator cannot alter the record. Check these settings against your Enterprise Edition role definitions before go-live.
Separation of administrator duties
An account that can manage users, change segregation settings and read audit logs could hide its own actions. Map each administrative task to a role, then assign audit, segregation and authentication settings to different people. Require two named people to approve changes to organization segregation and SSO configuration, and record each approval in your change process. Confirm what the platform's role model supports before you design around it.
Protection of storage and dependencies
OpenCTI depends on 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. Audit and segregation data passes through and rests on these services, so a weak point in any one of them can affect the record. Limit network access to each dependency to platform and worker nodes, encrypt stored data where your environment supports it, and confirm that each version meets the documented minimum.
Backup and retention of audit data
Audit data is useful only if it still exists when someone needs it. Plan backups of the search index and object storage together, since restoring one without the other may not produce a consistent platform. Set the retention period from your own policy, then confirm with the vendor how audit log retention is configured in your release. Run a test restore and check that audit records are present and readable afterward.
Integration service accounts
Connectors and integrations usually authenticate with a service account, and that account may read or write data across organizations without the user-level segregation that applies to people. Illustrative example: a connector token with broad access could write intelligence into a segment that a named analyst cannot see. Create one service account per integration, grant only the organizations and data types it needs, and include these accounts in the regular audit review.
Cost of an SSO change to access control
Since OpenCTI 7.260224.0, defining and using authentication strategies, including SSO, is an Enterprise Edition feature. Changing the identity provider or claim mapping can change who receives which role and organization, so an SSO change is also an access control change. Record current role assignments before cutover, test the new mapping with a small test group, and plan a rollback path. Ask for this work to be scoped in writing, since effort depends on the identity provider and the number of roles.
How to review audit logs without drowning in activity
A review routine turns activity monitoring from a log you own into a control you can demonstrate. Start by deciding which events matter for your obligations before anyone opens the audit log. For a threat intelligence platform that holds shared or regulated data, the high-value events usually include changes to users, roles, groups and organization settings, changes to authentication strategies (SSO configuration is an Enterprise Edition feature from 7.260224.0), changes to data segregation boundaries, and access to restricted or sensitive entities. Write this list down, agree it with the data owner, and treat everything else as background that can be sampled rather than read line by line.
Next, assign who reviews the events and how often. Name a primary reviewer and a backup, and where your organization is small enough to allow it, keep reviewers separate from the administrators whose changes they check. Give reviewers read access to activity and no ability to change the settings they review. Set the cadence from two inputs: how often the high-value events occur in your deployment and what your own policies or contracts require. The platform will not set this for you. Each review should leave a record showing the date, the scope covered, the reviewer, what was found and how each finding was closed.
Define the exceptions and how they escalate before the first review. Examples worth writing down include an administrative change with no matching change request, a member reaching data outside their organization segment, an unusual volume of exports, or a login from a source that is not on your expected list. For each exception type, record who is notified, the response window your policy sets, and who has authority to suspend an account or restrict access. Route these items through your existing incident process so that an audit log finding can become a tracked incident without someone having to reinvent the handoff.
Test the routine with activity you already know about before you rely on it. Create a test user, change one role, attempt a read across an organization boundary with a test account, and then confirm that each action appears with the expected actor, object, and timestamp. Keep the test results as evidence. Repeat the test after each upgrade, because logged events and their fields can change between releases. Confirm exactly what the audit log records, how long it is retained and which export options exist in the Enterprise Edition documentation for your specific release. DeployOpen can prepare the review procedure, role matrix, review records and test evidence. Independent auditors decide whether those controls meet a given standard.
Limits to confirm in your environment before you commit
The audit, segregation and hosting behavior in this topic depends on the exact version, license and deployment model you choose. Confirm each item below with Filigran or in the OpenCTI release documentation before you sign a contract or size hardware. Each card names one item to check and what to ask for.
Audit event and field coverage
Confirm exactly which activity monitoring events and audit log fields the Enterprise Edition records, including who acted, which object changed, when the change happened and where the request came from. Ask Filigran for the event catalog for your target version, and check the release documentation for events added or changed in later releases. Investigators and auditors can only answer questions that the recorded fields support, so test these fields against your real review questions.
Retention and export options
Confirm how long audit logs are kept, where they are stored, whether retention is configurable, and whether logs can be exported to your SIEM or archive in a format your team can parse. Ask whether export runs continuously or on demand, and who controls deletion. Write down your retention schedule and legal hold requirements before rollout so the vendor answers can be checked against them.
Segregation coverage by object and connector
Confirm whether organization-based data segregation applies to every object type in the knowledge schema, such as entities, relationships, indicators and files. Also confirm that connectors and workers apply the same boundaries when they write data. Ask Filigran how segregation handles connector-imported data and shared entities that more than one organization references. Test a sample of each object type and each connector in a non-production instance.
Behavior across LTS and regular upgrades
Confirm how audit logs, segregation settings and authorized member data carry through upgrades between regular releases and LTS lines. OpenCTI uses date-based versions, LTS releases require a specific LTS license key, and after stabilization they receive only critical bug and security fixes. Check the release documentation for migration notes for each target version, and ask Filigran whether any of these settings change when you move between the two tracks.
Performance impact on sizing
Confirm whether enabling activity monitoring and audit logs changes the sizing in the deployment overview. That guidance lists 2 cores and at least 8 GB RAM for the platform, 2 cores, 8 GB RAM and 16 GB SSD for Elasticsearch or OpenSearch, and at least one platform node for every 3 workers. Ask Filigran for any measured overhead on write volume, index growth and query latency, and run a load test at your expected event rate before you buy hardware.
Delivery model and data residency
Confirm whether on-premises or SaaS delivery meets your data residency, hosting location and access requirements. Filigran offers the Enterprise Edition in both forms, so ask how audit data, backups and vendor support access differ between the two models. Request written answers on where audit logs are stored, who can access them, and which regions and subprocessors are involved in your deployment.
Questions buyers ask about OpenCTI audit logs and segregation
Can the OpenCTI Community Edition provide audit logs and data segregation?
No. Activity monitoring and audit logs, organization-based data segregation and authorized members are Enterprise Edition features under the proprietary OpenCTI Enterprise Edition License. The Community Edition is licensed under Apache License 2.0 and does not include these features. Authentication strategies, including SSO, also moved behind the Enterprise Edition license starting with 7.260224.0, so a team that needs SAML or OpenID Connect sign-in with audit trails should plan for that as well. Feature availability can change between releases, so check the Enterprise Edition documentation for the exact release you run before you design around it. Ask Filigran or your implementation partner to confirm the feature set for your version in writing.
What does the OpenCTI Enterprise Edition license cost and how do I get a quote?
Filigran sets the Enterprise Edition license terms, so ask Filigran for the license price and terms that fit your deployment model, which Filigran offers on premises or as SaaS. Filigran also provides trial licenses and free licenses for development, research and non-governmental organizations. DeployOpen does not publish a price list. For implementation work, we write a fixed-scope quote from the scope you agree in writing, which lists the deliverables, platform components, integrations and testing. The license and the services are separate purchases. Ask for both in writing, and keep recurring license fees separate from one-time services so you can compare options accurately.
How long does an OpenCTI audit logs and segregation project take?
The duration depends on the scope, and no single figure applies to every organization. The main driver is the complexity of your organization model, meaning how many groups, teams and data boundaries must be separated, and how many authorized member roles map to them. Integrations matter because connectors and automations write data that must be attributed to the correct organization. SSO adds identity mapping work and its own testing. Test effort grows with each boundary you need to prove, including negative tests that confirm one group cannot see another group's data. A written scope lets us estimate the timeline for your environment before work starts. Ask for the milestones, test cases and dependencies in the quote.
What does our team need to provide for an OpenCTI segregation engagement?
Your team needs to provide named owners, a test plan, access and decisions on data ownership. Name a business owner for the data model, a technical owner for the platform, and an owner for each group that will hold intelligence. Agree on who approves the test plan, or ask us to draft one for your review. Provide access to the environment, including the platform, the identity provider and the infrastructure where OpenCTI runs, within your own access controls. Decide data ownership early: which group owns each intelligence source, who may share it and who can change visibility. List the integrations and connectors in use with their service accounts. Decisions made late usually cause rework in the data model and the tests.
Can our team set up OpenCTI audit logs and segregation without a partner?
Yes, a capable team can do this alone if it has the documentation for the release it runs and a clear data model. Start with the Enterprise Edition documentation, confirm the feature set for your version, and write down which groups need which data before you change any settings. Internal teams often handle platform configuration well, but verification usually takes the most planning, because proving that segregation holds requires deliberate negative testing and evidence capture. A partner helps most with design review, test cases and evidence packs that auditors can follow. Decide which parts your team keeps and which parts you outsource, and agree on who signs off each control.
Will DeployOpen make our OpenCTI deployment compliant with audit requirements?
No. DeployOpen prepares systems, controls and evidence for compliance assessments, but it does not issue audit reports, attestations or certifications. Independent auditors and certification bodies make the assessment. For this topic, we can help configure audit logging and organization segregation, document the control design, and assemble evidence such as configuration records and test results. Ask your auditor which control requirements apply to your environment and which evidence they expect, and confirm those expectations before design starts. The outcome depends on your processes, your evidence and the auditor's review.
How DeployOpen scopes and delivers OpenCTI access controls
DeployOpen plans, implements, documents and supports self-hosted OpenCTI inside your own cloud accounts, data centers or air-gapped networks. For audit logs and data segregation, we start by confirming whether your deployment needs the proprietary Enterprise Edition features, then design the organization model, authorized members and monitoring around your sharing and regulatory requirements.
How we scope
- Confirm which Enterprise Edition features your team needs, since activity monitoring, audit logs and organization-based segregation require the proprietary license
- Map which teams, partners and data owners must be separated into organizations and which data must stay visible across them
- Record who may grant and revoke authorized member access, and how those changes are approved and reviewed
- Agree the written scope, deliverables and timeline before any work starts, since most engagements are fixed-scope
How we build
- Configure organization boundaries and authorized member roles in a test instance, then test that data stays visible only to intended groups
- Set up audit log and activity monitoring retention, and confirm the events your investigators and auditors actually need to query
- Connect the chosen identity provider for sign-in, mapping group membership to OpenCTI roles where the license and version support it
- Run negative tests showing users outside a segregated organization cannot read, export or search its intelligence
How we hand over
- Provide configuration records for organizations, roles, authorized members and audit log settings, with the reason behind each boundary
- Document the access review procedure, including who runs it, how often, and the evidence it produces for internal or external assessors
- Deliver a runbook for onboarding and offboarding members and for investigating a logged activity event
- Explain which controls DeployOpen prepares as evidence and that independent auditors and certification bodies, not DeployOpen, issue any assessment result
How we support
- Ongoing support, upgrades and continuous testing are available as retainers after handover
- Review segregation rules and authorized member lists when your organization, partners or data sharing agreements change
- Plan OpenCTI upgrades with release and LTS line checks, so access controls are retested after each version change
- Confirm with Filigran which Enterprise Edition licensing and deployment options fit your environment before procurement
