Security & StandardsData Sovereignty
Modernization does not require surrendering control.
The first trust question is not which controls a system has. It is who controls the environment the system runs in — the data, the documents, the identities, the records, the backups and the logs. CREA-KO engineers systems so that answer can stay where it belongs: with the organization.
The custody question
Sovereignty is decided in the details nobody markets.
Ownership of a database is easy to claim. Custody is decided elsewhere: who holds administrative access, where the backups live, who can read the logs, what an export contains, and which knowledge exists only in a vendor’s head. Each of those is part of the same control question, and each is answered deliberately in how a system is engineered and contracted.
The deployment itself is chosen per environment — the organization’s own infrastructure where the mandate requires it, other controlled environments where appropriate. What does not vary is the allocation: infrastructure and operational data remain under client control where the deployment requires it, and the working knowledge of the system — documentation, configuration, operating procedures — remains usable by the client.
Custody and control
One boundary, drawn around what matters.
A conceptual model — deliberately not anyone’s architecture. The client-controlled environment forms the boundary. What needs custody sits inside it. Support and improvement cross inward through defined responsibilities; integrations exchange selected information through controlled interfaces; and there is no uncontrolled path out.
Crosses inward, under defined responsibility
Implementation & configuration
Delivered inside the client’s environment, under its authority.
Updates & maintenance
Improvements move inward under agreed scope — sensitive operational data does not move outward.
Support
Performed through defined responsibilities and access the client governs.
The client-controlled environment
- Operational data
- Documents
- Identities & roles
- Records & history
- Backups
- Logs
Held in governed custody — access by authorized roles, administration under the organization’s authority.
Integrations
Selected information exchanged with other systems through controlled interfaces — connection without surrender.
There is no fourth path. Uncontrolled export is not a smaller arrow on this model — it is absent from it.
What sovereignty requires
Control is an allocation, written down.
Ownership and custody, separated and named
Who owns the data, who administers the environment, who may access what — allocated explicitly, not left to habit.
Updates inward, not data outward
Improvements and fixes move into the environment under agreed scope; sensitive operational data does not leave it as a side effect.
Isolation where it matters
Client-specific data and configuration stay that client’s. No cross-client pooling of sensitive data or learned state.
Knowledge the client can use
Documentation, configuration and operating knowledge are deliverables — the organization is never held hostage to what only the vendor knows.
Stated plainly
What this page does not claim.
Not every deployment is on-premises, and no deployment model is declared unsafe by category. The right boundary follows from the environment, the risk, the contract and the operating responsibility — and the real arrangement for any system is specified there, not on a website. What is constant is the principle: the allocation of control is decided by the organization, engineered deliberately, and written down.
Start from who must hold control. We engineer to it.
Bring the custody requirements as they are — infrastructure, data, access, knowledge. The system is shaped around that allocation, and supported without loosening it.