Security & data sovereignty
The prompts stay inside your network too
The reason to own the engine is that the data never becomes someone else's asset. That has to be true of the AI as well, or it is not true at all — so GimCore is deployed with a local model on your hardware, and calling anything outside is a decision only you can take.
Where it runs
Every component sits inside a boundary you control
The application, the database and the language model are deployed on your own
infrastructure. A prompt is then a local function call rather than an outbound request, and
there is no third-party retention question because there is no third party. If your
organisation has no local model and chooses a hosted one, GimCore supports it and does not
recommend it — that call is yours, and it is configuration rather than architecture.
Outbound AI calls are written to an audit log inside your database, with the payload that
left, readable at /system/aicalllogs.
- Local inference — Ollama or LM Studio, on your hardware, and the default
- Your database — SQL Server, primary and optimised
- On-premise or your private cloud — your network, your backups, your keys
- Air-gapped deployment — available under the source licence
Inside your perimeter
Nothing in that list is hosted by us. There is no GimCore SaaS tenant holding a copy, because there is no GimCore SaaS tenant.
Accountability
The audit trail is recorded at three levels
An auditor's question is usually not "was it changed" but "could the record of the change have been changed". Three tiers are captured, so a single missing entry shows up as a disagreement between them rather than as silence.
All three tiers are written by the application; the third is not a database-level mechanism operating underneath it, and this page does not claim one. What tier 3 adds is the hash chain — an altered entry no longer matches the one after it. Nor does this site use the word "immutable": that is a stronger claim than three tiers, and it is not the one being made.
Access control
Who can see what
Access is decided on the record, not on the screen — so a report, an export and an API read answer the same way as the list a user opens.
- Company boundary — records carry the company that owns them, and reads are filtered on it
- Role filter — a record is visible to the roles it was written for
- Same rules everywhere — a chart cannot show a row its viewer could not open
- Identity from your IdP — OIDC today: Entra ID, Google Workspace. SAML 2.0 delivered on request
Governance and compliance are themselves modules — GRC, Privacy & Data Protection, Document Control, Whistleblowing, AI Governance. See the catalogue →
Standards
Design alignment, stated as design alignment
A control framework the architecture was built against is not the same thing as a certification, and a buyer's compliance team will know the difference within one question.
| Framework | What GimCore provides | Status |
|---|---|---|
| ISO 27001 | Architecture built to the practice — access control, logging, change control | Design alignment |
| SOC 2 | Control structure designed so the evidence an auditor asks for exists | Design alignment |
| GDPR | Data subject requests, consent register and processing register as a shipped module | Design alignment |
| Deployment location | Your infrastructure — no processor outside your perimeter | Property of the deployment |
| Certification held | — | None claimed |
Because the software runs inside your boundary, most of what an auditor examines is your control environment. What GimCore supplies is an architecture that does not stand in the way of it, and the evidence trail above.
Boundaries
What this page is not claiming
Written down rather than left out. A capability that is merely absent from a page gets reintroduced by the next person who writes one; a capability listed as absent does not.
- No certification. ISO 27001 and SOC 2 above are design alignment. GimCore holds neither certificate, and no page on this site says otherwise.
- No per-department row-level isolation. Access is by company and by role. Anything finer is a configuration exercise on your side, not a shipped feature.
- No digital signature of records. There is no qualified e-signature capability. Approval is workflow state plus the audit trail, which is a different guarantee.
- No penetration-test certificate published. If your process requires one, that is a scope item for the evaluation, not something to take on trust from a website.
- SAML 2.0 is not shipping today. OIDC is. SAML is delivered on request, scoped per deployment.
Every one of these is either in the claim register or absent from it on purpose. The register →
The next step
Have your security team test it
The 30-day evaluation runs on your infrastructure, which means your own team can examine the deployment rather than read about it. Bring the questionnaire.