Security is not claimed. It is proven
This page lists measures rather than principles, and for each one states where it is enforced and what proves it. Customer isolation sits in the database itself and is held there by tests that fail the build. The boundary around business data applies to us too, because it is set at the level of database rights rather than at the level of a promise. We do not hold an ISO 27001 certificate, and nowhere on this site will you read that we do — everything else on this page we can show you.
- Isolation in the database
- Control/Data Plane boundary
- Immutable journal
- SoD and maker-checker
- Backup, PITR and restore drill
- Support access on approval
What ERP security actually means
A business system rarely falls to an attacker outside. It breaks from within far more often — through an account that saw too much, a change nobody recorded, or a backup that was never restored.
So NG One treats security as a property of the model rather than a layer around the application. Isolation between customers sits in the database itself: a Row Level Security policy in FORCE mode applies to every row, and the role the application runs under has no right to bypass it. This is not a filter a developer may omit from a query — it is a rule the database enforces even when the query is wrong. Two tests fail the build if anything departs from it: one checks that no table holding customer data is missing its policy, the other tries to read and modify one customer's data from another's context and requires the attempt to fail.
The second boundary is internal. Running the platform is a separate product with its own schema and its own roles, not the largest account in the system: platform staff have no default access to a customer's business data — not because they refrain, but because they hold no rights over those tables in the database. When access is genuinely needed, there is exactly one route: a request with a reason, a scope and a duration, approval by the customer's administrator inside their own system, a session with a visible banner that expires by itself, and a record in two journals. The customer then receives a report of what was done.
The third layer is proof. An ERP is not secure until a restore has actually been performed, so restoring from backup is not a line in a proposal here but an automated monthly drill — the date of its last success is a visible figure in the customer health view, not a sentence somebody says to you in a meeting. The same principle governs authorisation: a rule with no record is not a rule, so every action, every configuration change and every data export stays in a journal that is never rewritten after the fact.
Six principles
These are not slogans — each is a recorded architectural decision, and each produces at least one measure further down this page. A principle with no measure is decoration; a measure with no principle is an accident.
Isolation is a property of the database
Customer data shares a database but never shares a row. Row Level Security in FORCE mode, a runtime role with no right to bypass it, the tenant context set at the start of every transaction, and a meta-test that fails the build on any departure. The application cannot make a mistake the database does not stop.
Fail closed, not fail open
When the context is missing, when a right was not explicitly granted, when a policy is undefined — the answer is refusal, not passage. Authorisation is enforced on the server from the very first use case; the front end displays permissions but never decides on them.
Least privilege, ourselves included
Platform staff have no default access to business data — the boundary is set at the level of database rights, not at the level of a behaviour policy. The same rule applies inside a customer: data scope is part of the authorisation decision, and prohibitions on payroll and margins are a separate dimension independent of the role.
A rule with no record is not a rule
An immutable journal of business actions, a configuration change log, the state history of every document, the decision record inside every approval, and a record of every export. When somebody asks a year later who did what and under which setting, the answer is read rather than reconstructed.
Critical actions require two people
Segregation of duties prevents incompatible powers from gathering on one account, and maker-checker requires a second pair of eyes where a mistake or an abuse costs the most. On the platform side it is mandatory for suspension, termination, entitlement overrides and any deletion.
Recovery is proven, not promised
A backup with no restore behind it is an assumption. Here, restoring is an automated drill whose last success date is visible in the health view — a figure you can ask for whenever you like, rather than a claim you get to verify on the one day that is the worst possible time to verify it.
Data protection
The measures that concern the data itself: where it sits, who sees it, how it is kept, and what happens when you ask for it back.
Customer isolation in the database
Every table holding customer data carries a tenant identifier and a Row Level Security policy in FORCE mode. The runtime role has no bypass right; the context is set per transaction. A meta-test over the schema fails the build if a table is left without its policy or its index, and an isolation test attempts access across the boundary and requires it to fail. Both tests run on every change, and their output is an artefact in the repository.
The Control/Data Plane boundary
Platform management lives in a separate schema with separate roles and mandatory multi-factor sign-in. Platform staff have no default access to the business tables — the right does not exist, so the query does not succeed. Everything the platform knows about a customer's operation is aggregated, anonymised metrics, and dimensions that would reveal business data are hashed before they leave the customer's context.
Six layers of authorisation
Roles and permissions, data scope, approval limits, segregation of duties, maker-checker, and delegation with cover — all six exist, and all six are enforced on the server. A layer that does not exist from the first use case means every use case written until then was written without it; that is why NG One carries all six from the first line rather than as a layer stretched over a finished system.
Segregation of duties and maker-checker
The matrix of incompatible powers is checked both when a role is granted and at the action itself, so a conflict cannot be assembled out of temporary rights. Maker-checker requires a second person on critical actions, and what counts as critical is the customer's configuration — except on the platform side, where the list is fixed.
Encryption of sensitive data
Column-level encryption at rest for passwords, secrets and personal data from payroll, with key management: rotation and envelope encryption, so rotating a key does not mean re-encrypting everything. Passwords go through Argon2id. What counts as sensitive is decided during a module's threat modelling, not after delivery.
Immutable journal
An append-only record of business actions (who, what, when, against what, from which context), a configuration change log with the old and new value, document state history with the guard that permitted the transition, and the decision record inside an approval — what the approver saw at that moment, not what the document says today. None of it is rewritten after the fact.
Support access on the customer's approval
The only route to business data from outside. An engineer requests access with a reason, a scope (read-only by rule, by module) and a duration of up to eight hours; the customer's administrator approves it in their own system. The session runs with a restricted scope, shows a visible banner, expires by itself and is recorded in both journals. The customer receives a full report. Ahead of any request stands a diagnostic bundle with no personal data, which resolves most cases without entering the data.
Antivirus scanning of attachments
Attachments go to S3-compatible object storage and are scanned before the system accepts them — not afterwards. A retention policy per document category accompanies them, aligned with archival periods.
Anonymisation for test and demo
Production data is not copied into a test environment as it stands. Personal data is masked under data protection rules, so the test environment carries a realistic shape of data without its content.
Every measure on this list has a place where it is enforced: the database, the server, or CI. None of them relies on the interface hiding a button — an authorisation decision made in the browser is not a decision but a suggestion, and we treat it as one.
Production operations and the security programme
This is the part proposals skip most often and the only part that counts during an incident: how code reaches production, what is visible while the system runs, and what happens on the day something breaks.
Backup, PITR and a proven restore drill
Automated backups with WAL archiving, meaning recovery to a point in time rather than only to last night. The restore is tested by an automated monthly drill, and the date of the last successful restore is a visible figure in the customer health view. RPO and RTO are set per delivery plan and written into the contract. A backup that has never been restored is an assumption — which is why the restore runs on a schedule rather than for the first time on the day it is needed.
Observability on OpenTelemetry
Structured logs with a trace identifier, metrics and tracing through OpenTelemetry into Prometheus, Grafana, Loki and Tempo. Health, readiness and liveness probes, alerts on deviations. When something goes wrong the question is not whether we have logs but which line to open.
Feature flags per customer
Deployment and release are separated: code ships to production switched off and is enabled per customer or per percentage. The practical consequence is that risky functionality does not reach everyone at once and can be switched off without a new release.
Zero-downtime migrations and version rollback
Database changes follow the expand–contract pattern: never a destructive change in the same release as the code that uses it, so the old and new application versions overlap without an outage. A CI check hunts for destructive changes, and rolling back to the previous application version is part of the procedure rather than an improvisation.
Secrets management
Secrets live in the environment or a secret store, with rotation, and never in code, in the repository or in logs. The application fails immediately when a secret is missing rather than running with a default — a system quietly started with an empty key is worse than one that stopped.
gitleaks in CI and before push
A secret scanner runs as a pre-push hook and as a mandatory CI gate, so a credential never reaches a branch, let alone a release. This is not a theoretical measure — in the systems customers are leaving, a committed token is the most common finding.
Threat modelling per module
The threat model is produced while a module is being designed, not after it ships — the question of what can go wrong here is asked while the answer is still cheap. The output is a concrete list of controls for that module, not a document filed away.
OWASP ASVS as an acceptance criterion
The ASVS baseline is an item in the Definition of Done of every step, therefore a condition for closing it at all. That is the difference between security as a culture and security as a pre-launch review, which always arrives too late.
Prompt-injection tests in CI
The AI layer reads business data, so it treats the content of a document as input from an untrusted source: text in an attachment, an email or a line description cannot become an instruction. A corpus of adversarial prompts runs as a CI gate, and the AI operates under the permissions and data scope of the user who invoked it — the model holds no right the user does not.
Legal hold and retention policy
Retention is a policy per document category, aligned with statutory keeping periods. A legal hold freezes deletion for the scope under dispute or inspection, regardless of the policy — and is itself recorded, because a freeze is also an action somebody decided on.
Export and controlled termination
A customer can obtain a complete export of their data at any time; export keeps working even while an account is suspended for non-payment. Termination is a procedure with an order to it: the export is handed over before anything is deleted, and deletion is carried out under control and leaves proof. Every export is recorded — who, what, when and at what scope.
External penetration testing
External penetration testing runs on a schedule: before every go-live wave and annually thereafter. Findings enter the same workflow as everything else — an owner, a deadline, and a test that stops the same mistake from returning. The result of a penetration test is not a badge for a website but an entry in the backlog; it goes to your security team under NDA, not to visitors.
The numbers that would look persuasive here — availability percentages, scan scores, incident counts — are not on this page, because they cannot be verified from the other side of a screen, and an unverifiable number is marketing rather than data. What can be verified are the procedures, the acceptance criteria and the tests in CI. We walk your team through those, line by line.
Compliance with personal data law
The GDPR and the Serbian Personal Data Protection Act require tools, not statements. Here are the tools, and where they sit in the system.
NG One is built so a customer can meet their obligations as a controller: to know which personal data they hold, to answer a data subject request, to prove who accessed it, and to erase it once the period expires — except where another regulation or a legal hold forbids erasure. Our role in that relationship is the processor's, and it is governed by contract rather than by a sentence on a website.
What the platform carries as a built-in measure is the boundary: customer data is isolated in the database, platform staff do not see it by default, and any support access is approved, time-boxed and recorded in two journals. Anonymisation for test environments exists precisely because copying production into test is the most common way personal data leaks out of systems that are formally compliant.
We claim nothing here that we cannot show. NG One holds neither an ISO 27001 nor a SOC 2 certificate, and this page will not suggest otherwise. A certificate is in any case a document about a process rather than about a product — we would rather show you the product: the isolation model, the six layers of authorisation, the journals, the acceptance criteria, and the tests that fail the build the moment somebody departs from them. We are ready to walk your security team through all of it before you sign anything.
Data subject rights
Tools for answering a request: a view of one person's data across modules, rectification, restriction of processing, and erasure with a check against statutory retention. The request and its outcome stay in the journal, because answering a request also has to be proven.
Records of processing activities
Support for maintaining the record of processing a controller is obliged to keep: which category of data, on what legal basis, for how long, and who has access to it. The record derives from the system's configuration rather than being maintained in parallel in a spreadsheet.
Masking personal data outside production
Test and demo environments receive data with personal content masked. The shape of the data stays realistic, the content does not exist — so the test environment stops being the weakest link in your protection.
Retention, legal hold and provable erasure
The retention period is a policy per category, a legal hold overrides it while a dispute or inspection lasts, and erasure on termination is a controlled procedure that leaves proof it was carried out. The order is always the same: export to the customer, then erasure.
Record of data exports
Every export — from a list, through the API, or as a full customer export — records who exported, what, when and at what scope. Without this, export is the gap in the trail through which everything the journal carefully recorded simply walks out.
Konis Software holds neither an ISO 27001 nor a SOC 2 certificate, and NG One is not marketed as certified. This page describes the measures built into the product and the place where each one is enforced. Controller and processor roles, the place of processing, incident notification deadlines and sub-processors are governed by the data processing agreement.
How is one customer's data separated from another's?
By a policy in the database itself. Every table holding customer data carries a tenant identifier and a Row Level Security policy in FORCE mode, and the role the application runs under has no right to bypass it — so this is not a condition in a query a developer might forget, it is a rule PostgreSQL applies to every row regardless of how the query was written. The tenant context is set at the start of each transaction. Two tests fail the build on any departure: one checks that no table holding customer data is left without its policy and its index, the other tries to read, insert, update and delete another customer's data from one customer's context and requires every attempt to fail. Both run on every change and their output is an artefact in the repository — we can show it to you.
Can anyone at Konis see our data?
Not by default, and that is a matter of database rights rather than a behaviour policy. Platform management is a separate product with its own schema and its own roles; those roles hold no rights over the business tables, so a query that would read them fails even if someone wrote it. There is a test that proves it: a platform administrator's attempt to open business data must be refused and must leave a record. When access is genuinely needed for support it runs exclusively through Support Access — a request with a reason and a duration, your approval inside your own system, a session with a visible banner that expires by itself, a record in both journals, and a report delivered to you afterwards. A diagnostic bundle with no personal data always comes first, and it resolves most cases without touching the data at all.
Do you have ISO 27001 or SOC 2?
No. We hold neither certificate, and we will not claim what we cannot show — this page would look more persuasive with two badges on it, and it would be untrue. What we do have is the security programme standing behind every measure on this page: threat modelling while each module is designed, an ASVS baseline as a condition for closing any step, isolation held in place by tests in CI, encryption of sensitive data with key rotation, a restore proven by drill, support access only on your approval, and external penetration testing before every go-live wave. If a certificate is a procurement requirement for you, tell us at the start of the conversation — better you know now than six months in. If the requirement is a secure system, take this page to your own security team and demand evidence for every line on it; we have it for every line.
What if we lose data — how far back can it be recovered?
Backups are automated with transaction log archiving, which means recovery to a point in time rather than only to the last nightly copy. The specific RPO and RTO are set per delivery plan and enter the contract, because they depend on how you work and how many lost minutes your business can absorb. More important than the number is that the restore is proven: it runs as an automated monthly drill, and the date of the last successful restore is a visible figure in the health view of your account — you do not have to take our word for it, look at the date. A backup that has never been restored is an assumption rather than a backup, and assumptions collapse on exactly the day you were counting on them.
How do you prevent abuse from the inside?
With four measures that work together. Data scope limits what a user can see at all — by legal entity, warehouse, department or cost centre — and that is a server decision, not an interface filter. Segregation of duties prevents incompatible powers from gathering on one account, and is checked both when a role is granted and at the action itself, so a conflict cannot be assembled from temporary rights. Maker-checker requires a second person on critical actions. And the immutable journal makes every action visible in hindsight, including configuration changes and every data export. None of the four is sufficient alone; together they cover the scenario in which one account slowly widens its own rights.
Do you use our data to train AI models?
No. The AI layer works over your data to answer your question, in your context and under your permissions and data scope — but customer data is not a source for training models. The model gateway has a replaceable provider, a budget and quota per customer, visible cost, redaction of personal data before sending, and an AI journal recording which model and which prompt version were used. Every AI answer leads back to the source document, because an answer with no trace to data in the ERP is not usable. And whatever the AI proposes arrives as a draft a person confirms — the model does not post, it prepares.
Where is the data physically located?
The place of processing is agreed and written into the contract — not as a formality, but as an input to the architecture of your installation. On-premise installation is supported with a signed offline licence, without the system needing to phone home to check it; for some customers that is a requirement rather than a preference, which is why it is solved in the licensing model rather than by exception. Attachments go to S3-compatible object storage, which can be self-hosted. If you have a requirement about data location — jurisdiction, the legal entity holding the infrastructure, or the physical location of the servers — raise it before signature: a requirement like that is built into the installation, not resolved after it.
Bring your security team to this conversation
We walk through the isolation model, authorisation, the journals, the recovery plan and the boundary around your data — with the documentation and the tests on the table. We would rather answer hard questions now than easy ones after signature.