Security and compliance
Three properties define the posture: identity stays in your provider, tenant isolation is designed at the database level rather than in application logic, and the entire source is auditable before adoption.
Read the isolation section carefully: what the platform supports and what the reference deployment configures are not the same thing.
The platform can run fully disconnected from the internet, with no licence check, telemetry callback or hosted dependency.
Certification status
IntelliStream is working toward ISO/IEC 27001 certification. That process is in progress and not yet complete, we are not certified today, and this page should not be read as a claim that we are.
What that means practically for an evaluation:
- The information security management system is being built out against the standard, so the controls and documentation a certified supplier would be expected to hold are being put in place rather than assembled reactively.
- If your procurement process requires a certified supplier today, we do not meet that bar yet. Ask us where the process currently stands rather than relying on this page, which is updated less often than the programme moves.
- ISO/IEC 27001 certification covers the organisation's management system, not the software itself. The properties below, external identity, credential-level tenant isolation, and a fully auditable source tree, are what a technical review should actually examine, and they hold independently of certification status.
Authentication and authorisation
Identity is external. DataHub holds no user accounts and no passwords. Authentication is OAuth2/OIDC against your identity provider, so your existing single sign-on, multi-factor requirements, conditional access and joiner-mover-leaver process all apply unchanged. Identity providers, including Entra ID →
Authorisation is per request. Every request is authorised against your identity provider's current answer, so revoking a role or a group membership takes effect within about a minute, without waiting for the user's token to expire. If the identity provider cannot be reached, requests are refused rather than served with a stale or empty answer.
The API holds no sessions. It is a stateless resource server. The console does hold sessions, externalised to a shared store, which is what lets it scale without affinity.
Live delivery is authorised the same way. A data subscription is an authenticated, permission-scoped standing connection, not a bypass: what it delivers is filtered by the same data set read boundary as any other read.
Users and access → · Data set permissions →
Tenant isolation
This is usually the question a risk committee cares most about, and the answer is stronger than in most multi-tenant platforms.
Each tenant has its own relational and columnar databases and its own file storage root. The platform supports giving each of those its own credentials, so that cross-tenant access requires a credential compromise rather than an application bug.
The reference deployment does not configure it that way. As shipped, tenants share one PostgreSQL/ClickHouse credential, and because Neo4j Community Edition supports only a single database, all tenants share one graph database. Those are deployment choices you can change, and you must change them before the isolation argument above holds. Detail →
Two caveats inside a tenant belong in the same review, both documented in detail on the permissions page: graph traversal is gated on the starting node only, so data sets are not barriers within a connected graph, and files with no data set are readable by every authenticated user.
That is a meaningfully different guarantee from schema-based or row-based separation, where a single mistake in query construction can cross the boundary.
Additional defence in depth on the shared-capable stores:
- Key-mapping store keys are 128-bit cryptographic hashes of the external id combined with the tenant id, so a key is infeasible to guess and cannot collide across tenants.
- Cached query cursors are held under unguessable time-ordered keys with a short expiry that refreshes while a result set is still being paged through.
The tenant is resolved from the organisation claim in the caller's token, and the tenant context is explicitly cleared at the end of every request so it cannot leak between users sharing a server thread.
Secrets
Credentials and the tenant registry live in a dedicated secret store with access control and audit, not in application configuration files or database tables. Services authenticate to it at startup and load only what they need.
The tenant registry is in the secret store for a structural reason as well as a security one: it decides which database to connect to, so it cannot live in one of those databases.
Auditability of the platform itself
The source code is public, under the GNU AGPL-3.0. That changes what a security review can actually do:
- Read the code rather than relying on a vendor questionnaire
- Verify what the platform does with your data, rather than being told
- Run it fully air-gapped, with no outbound connection required at runtime
- Continue running it independently if the supplier ceases to exist
For organisations in regulated or critical-infrastructure sectors, the air-gap capability and the source availability are often the deciding factors rather than nice-to-haves.
Data protection questions
Where does our data go?
Wherever you run the platform. There is no hosted component in a self-managed installation, no telemetry, and no callback. Data residency is determined entirely by where you place the databases, and because each tenant carries its own connection details, different tenants can sit in different jurisdictions.
Can we delete a tenant's data completely?
Yes, and cleanly. Because every store is database-per-tenant, offboarding is dropping the tenant's databases and removing its storage root, there is no residue in shared tables to hunt for, because there are no shared tables. Removed tenants' folders are quarantined for 30 days and then purged automatically. Offboarding →
Can we prove a document has not been altered?
Every uploaded file records a checksum, so a document filed in DataHub can be verified against it. Files →
Can we prove where a reported figure came from?
Not end to end today. Full lineage, where every derived value records the transformations and inputs behind it with data-quality flags at each step, is on the roadmap. Do not offer it to an auditor as an existing control.
What you can show today is that a figure was produced from one queryable model rather than from an assembled spreadsheet, and that it reproduces. That is a real improvement on the usual position, and it is a smaller claim than traceability.
One caveat worth planning for now, because it is a retention decision rather than a software one: lineage will only ever trace to inputs that still exist. If retention removes measurements before an audit occurs, the ancestry records what a figure was computed from but the inputs themselves are gone. Align retention with your audit horizon deliberately. Retention versus traceability →
Production hardening checklist
The evaluation stack is deliberately convenient and deliberately insecure. Before production:
Console, API, streaming platform, and every database connection.
Demo tenants, demo users and default administrator passwords must not survive.
With your groups, your MFA policy and your leaver process.
Per-tenant database roles, proper credentials, and network policy limiting who can reach the stores at all.
Ingestion accounts get write and not read, and read-only credentials on the source system they read from. Why →
Roles granting access to all data sets should have a short, reviewed list of holders.
Per tenant, with a restore actually exercised rather than assumed. Backups →
Both directions: long enough for audit, short enough for data minimisation.
Reporting a vulnerability
Security issues should be reported through the process published in the platform repository's security policy, rather than through public issue tracking.
- Organisations and tenants: the isolation model in detail
- Identity providers: Keycloak, and bringing in Entra ID
- Data set permissions: how read and write are granted
- Data lifecycle: retention, backups and deletion
- Board briefing: the governance-level summary