Deny-by-default, anti-IDOR protection, full tenant isolation and granular control of access to data.
What problem it solves
In a system that holds an organisation’s documents, the question is not whether data is protected in general, but who exactly can see a given document, at a given moment, and what trace that access leaves. Regulation (EU) 2016/679 asks for exactly this level of precision: a legal basis for processing, data minimisation, access limited to what is necessary, and the ability to prove all of it at an inspection.
Most incidents in business applications do not come from broken cryptography but from wrong authorisation. An identifier guessed in the page address, a role that inherits more than it should, a query that forgets to filter by organisation — all lead to the same result: someone sees a document that is not theirs.
How protection is built in VOGO eBS ECM
Authorisation starts from refusal. Any request that does not explicitly match an access rule is refused; there is no permissive default behaviour someone could forget to restrict. The rule is applied on the server, at every request, not in the interface — a request sent directly, without going through the screen, follows the same path.
Each organisation’s data is isolated at tenant level. The separation is not a condition added at the end of a query, but part of how access to data is built, so that a badly written query cannot, by omission, pull data from another tenant.
Anti-IDOR protection — insecure direct object reference — means that an object’s identifier is not, by itself, an access key. Knowing or guessing a document’s number does not give a user the right to open it; the right is checked separately, on the specific object.
- separate rights to consult, create, change and cancel, configurable on each component;
- access checked on the server, at every request, regardless of what the interface shows;
- tenant isolation, part of how access is built, not a condition added afterwards;
- an audit log for operations on documents and entries.
What the organisation gains
A data controller that receives an access, rectification or erasure request must answer on time and be able to show what it did. A system where access is checked consistently and operations leave a trace turns these requests from an investigation project into a query.
The same goes for inspections. The question “who had access to this file and when” is answered from the log, not by reconstruction. And a clear separation between roles shortens the discussion about responsibility: you can see who could do what.
Questions and answers
Is the platform GDPR compliant?
Compliance belongs to the data controller, not to a software product. The platform provides the mechanisms the controller relies on: deny-by-default authorisation, tenant isolation, role-based rights and an audit log. The actual configuration, the legal bases for processing and the retention policies remain the organisation’s decisions.
What does deny-by-default mean in practice?
It means a request without an access rule that explicitly allows it is refused. In practice: a forgotten right does not become a right granted by mistake.
How is isolation between organisations checked?
Tenant separation is part of how access to data is built, not a condition added to each query. We can show you the mechanism in a technical demonstration.
Can it integrate with existing internal security policies?
Yes. Rights are defined on roles, and roles can be aligned with the organisational structure and the policies already approved. Integration with an identity directory is discussed separately, depending on your infrastructure.