01
Choose the boundary you need
Run Kordon in your own infrastructure when you need tighter control over data location, access paths, network exposure, or internal hosting policy.
On-Premises GRC
On-Premises GRC Platform
Kordon can run inside your own infrastructure when policy, data boundary, or deployment requirements rule out vendor-hosted SaaS. If you're evaluating an on-premise GRC platform, you still get the same connected system for risks, controls, tasks, evidence, assets, vendors, and business processes.
How it works
From deployment requirement to a live security program
On-premises GRC is judged on whether the system still makes security and compliance work operational once it is inside your environment, not on where the software lives.
02
Map your real operating context
Document the assets, vendors, business processes, risks, and framework requirements that matter to your organisation instead of forcing everything into a generic template.
03
Connect controls to execution
Link each control to the risks it mitigates and the requirements it satisfies, then operationalise it through recurring tasks owned by the people responsible for the work.
04
Keep proof flowing continuously
As tasks are completed, evidence accumulates, auditors get clear traceability, and the platform reflects whether your program is working as designed or drifting out of shape. How audit management works in Kordon →
Built for constrained environments
An on-premises GRC platform without the usual compromise
On-prem deployment changes where the platform runs. Kordon keeps the same operating model whether you host it in your own environment or use our cloud deployment.
Run it in your own infrastructure
Deploy Kordon inside the environment you control when internal hosting policy, network segmentation, or customer requirements make vendor-hosted SaaS a bad fit.
One connected system
Risks, controls, requirements, tasks, evidence, assets, vendors, and business processes stay connected in one place instead of being scattered across spreadsheets and folders.
Controls become operational work
Kordon turns policies and controls into recurring tasks, ownership, reminders, and evidence so the program keeps running inside your environment instead of turning into static documentation.
Fit the platform to your model
Use custom fields, labels, permissions, and structure that reflect how your organisation works instead of reshaping your program around a vendor's default schema. Still comparing categories? See how GRC tools, software, and platforms differ →
Bring more people into the program
Give control owners, risk owners, auditors, and operational stakeholders clear visibility and responsibility without turning the security team into a documentation bottleneck.
Keep your integrations
API access and automation matter on-premises. Connect Kordon to the rest of your toolchain and keep evidence collection, workflows, and reporting tied into your environment. How GRC engineering works in Kordon →
Deployment
What changes when you host it yourself, and what doesn't
Data residency is usually what brings people to this page, and both Kordon deployments answer it: the hosted platform runs in Finland or Germany, or you run the whole thing yourself. A self-hosted edition is often a cut-down one, a release behind the hosted version or carrying integrations that quietly route back through the vendor's cloud. Kordon changes the deployment target and nothing else.
| Kordon Cloud | Your own infrastructure | |
|---|---|---|
| Where the data physically sits | Kordon CloudIn the EU, in the country you pick. Choose Finland or Germany when the account is set up, and your data stays in that region. | Your own infrastructureWherever you put it. Data residency stops being a question you have to take a vendor's word on. |
| Object model, interface, permissions | Kordon CloudFull platform | Your own infrastructureThe same platform, at the same version |
| REST API and n8n node | Kordon CloudComplete API, official n8n node | Your own infrastructureSame API, same node. No capability is reserved for the hosted tier. |
| What you run it on | Kordon CloudWe operate it | Your own infrastructureA Docker container on standard Linux infrastructure, configured through environment variables |
| HTTPS | Kordon CloudManaged | Your own infrastructureBuilt into the container, so there is no separate reverse proxy to stand up |
| Single sign-on | Kordon CloudGoogle Workspace, Microsoft Entra, Okta, Keycloak | Your own infrastructureThe same four, built into the container rather than needing an identity proxy alongside it |
| Automated user provisioning | Kordon CloudSCIM 2.0 with Entra, Okta, OneLogin and Google Workspace | Your own infrastructureSame |
| Where evidence files are stored | Kordon CloudManaged by us | Your own infrastructureLocal filesystem, Google Cloud Storage or AWS S3, in a bucket you own |
| Framework content | Kordon CloudISO 27001, SOC 2, NIS2, DORA, E-ITS, ISO 9001, ISO 14001 and hundreds more preloaded, plus your own internal frameworks as custom requirements | Your own infrastructureThe same library, preloaded. One control can satisfy requirements across several frameworks at once. See how framework management works → |
| AI and agents | Kordon CloudBring your own agent. No model is embedded in the platform. Agents connect through the REST API, the official n8n node and purpose-built Kordon skills, using whichever framework you already work in. How agentic GRC works → | Your own infrastructureIdentical, and it is what keeps the boundary intact: because the model is never inside the platform, your agent and its inference can live wherever you need them to, including on hardware inside your own network |
| Upgrades, backups, uptime, capacity | Kordon CloudOur responsibility | Your own infrastructureYours, on your change schedule rather than ours |
Common questions
Data residency and self-hosting, answered
Do we need on-premises to keep our data in the EU?
Often not, and it is worth checking before you take on the operational work. Kordon Cloud runs in the EU, and you choose Finland or Germany when the account is set up. If a named EU region under GDPR is what your requirement asks for, that is the end of the question. Self-hosting is the answer when the requirement goes further than geography: a national hosting policy that names your own infrastructure, a sector rule about who may hold the data, a customer contract that rules out multi-tenant environments, or a board that will not accept an ISMS in another company's cloud. Both routes run the same platform, so this is a question about your obligations rather than about which product you get. One thing to check with any vendor claiming EU residency: whether the region named in the marketing is the region in the URL, and whether their AI features stay in it.
Is the on-premises version a reduced edition of the platform?
No. It is the same application as the hosted deployment: the same object model, the same complete REST API, the same official n8n node, the same permissions model, and the same preloaded framework library covering ISO 27001, SOC 2, NIS2, DORA, E-ITS, ISO 9001, ISO 14001 and hundreds of other standards, plus any internal framework you add as custom requirements. Self-hosting is a deployment choice, not a feature tier. This is worth checking with any vendor: it is common for a self-hosted edition to lag the hosted one by a release, or for integrations to quietly route through the vendor's cloud, which defeats the reason for deploying inside your own boundary in the first place.
What infrastructure do we need to provide?
A Linux environment able to run a Docker container, plus somewhere to keep evidence files. Configuration is entirely through environment variables, TLS is built into the container so there is no separate reverse proxy to stand up, and evidence storage can point at the local filesystem, Google Cloud Storage or AWS S3. Kordon uses server-side pagination and filtering, so it stays responsive at tens of thousands of assets and tasks rather than needing to be sized around a small dataset.
Where does AI processing happen in a self-hosted deployment?
Wherever you decide it should. Kordon is built bring-your-own-agent: no model is embedded in the platform. Agents connect through the complete REST API, the official n8n node, and purpose-built Kordon skills, and any framework works, whether that is Claude, LangChain, n8n or something your own team wrote. With no model of our own to route it to, nothing sends your evidence outward by default: point an agent at a model running on your own hardware and inference stays in the same boundary as the data, scoped by the same permissions model that governs your people. This is the question worth putting to every GRC vendor on a residency review, because it is where residency promises usually break down. A platform can sit in your region and still send every document it reasons over to a model endpoint somewhere else. Ask where inference happens, not only where the database sits.
Who applies updates, and on whose schedule?
You do, on your own change schedule, which is usually the point of self-hosting in the first place. Worth asking any vendor how long a given self-hosted release stays supported, because a self-hosted platform nobody upgrades turns into its own audit finding within a couple of years.
Can we start on Kordon Cloud and move to our own infrastructure later?
Yes. Because both deployments run the same application against the same object model, the programme you build in one is the programme you run in the other. You can start hosted while you are still shaping your control set and framework scope, then move in-house once a customer requirement, a regulator or an internal hosting policy makes the boundary firm.
Does an on-premises deployment still support SSO and automated provisioning?
Yes, and without extra moving parts. Single sign-on for Google Workspace, Microsoft Entra, Okta and Keycloak is built into the Kordon container rather than requiring a separate Keycloak instance or authentication proxy alongside it, and SCIM 2.0 provisioning works with Entra, Okta, OneLogin and Google Workspace. Users are created and deactivated in Kordon automatically as they change in your identity provider.
Who is on-premises GRC actually for?
Teams whose deployment boundary is set by someone other than them: a regulator, a national hosting policy, a customer's security questionnaire, or a board that will not accept an ISMS in another company's cloud. That is a different situation from preferring self-hosting. If you already operate your own infrastructure and have the team to run it, hosting a GRC platform there is not an extra burden you are taking on; it is the environment you already work in. If you do not, Kordon Cloud is the same platform without the operational load.