Security & Your Data
Two questions, answered before you ask them
Any company evaluating a business platform has the same two worries, and they are rarely the ones the sales material addresses: where does my data physically sit, and what happens the day something goes badly wrong.
Where your data sits is your decision
A GTSuite installation is the same installation wherever it runs.
- On your own server, in your building or in a data centre you already use, with nothing leaving your network.
- On our hosted service, if you would rather not run servers and databases at all.
- Moved later, in either direction, because it is the same software either way.
Both patterns are in use today. This is worth settling early, because data residency is often a compliance obligation or a clause in a contract with your own customers, and it should not be dictated by the software you happened to choose.
Your business data lives in a standard relational database with readable tables. Your own tools reach it, your own backup policy covers it, and your own people can audit it.
Who can see what, down to the single button
Access control in most business software stops at the screen: a user either has the page or does not. Real companies need finer distinctions than that. Two people may need the same order list in front of them, while only one of them should be able to cancel an order, and the other has no use for half the columns.
In GTSuite permissions are part of the application's definitions, like everything else. You create as many roles as your organisation actually has, and grant each one the menu entries it needs. Then, where a whole screen is too coarse, you take a single element, declare it as a controlled object and grant it to the roles allowed to have it. Three kinds of element can be controlled this way:
- A button or a command, so the same page can be read only for one role and operational for another.
- A single column of a table, so a list shared by several roles does not have to put every figure in front of all of them.
- A report, granted to the roles that should be able to run it.
All three are live in systems running today, and none of them required a line of code: an object is listed as controlled, and the roles are granted.
A distinction worth making: granting objects tailors a screen to a role. Where information must genuinely not reach someone, the right instrument is the data itself, giving that role a page whose query does not return the figure at all. The two are often confused in this kind of documentation, and they are not the same thing.
Two roles always exist in every project. One is the administrator, who sees everything by default. The other belongs to whoever is building the application, and it is what holds work in progress: a page granted to it is visible to the people developing it and to nobody else.
Why this matters more than it sounds: it means a new page can be built and tested on the live installation, with real data, while your users continue working and never see it. It becomes theirs the day you grant it. There is no separate staging system to keep synchronised, and no release evening.
Backups built for the bad day
Most backup arrangements are designed against hardware failure. That is the easy case. The hard case is an attacker who gets administrative control of a server, because the first thing modern ransomware does is destroy the backups before encrypting anything.
GTSuite includes an encrypted off site backup mechanism designed against exactly that. It rests on one principle:
The system that produces the backups is not the authority that guards them.
In practice, each night the databases are dumped, bundled and encrypted, then shipped to a second machine in another location. Custody of what arrives is handled by the operating system of that receiving machine, entirely outside the application. An attacker who takes over the sending server, application and all, still cannot reach back and destroy the history that is already there.
How it holds up
| What could happen | What stops it |
|---|---|
| Someone steals or copies the archives | They are encrypted to a public key. The private key that could open them is kept offline and has never been on any server. |
| A server is fully compromised and the attacker reads its backups | That server can encrypt but cannot decrypt. It holds ciphertext it cannot open, including its own. |
| The attacker uses the transfer credentials to reach the other machine | Those credentials belong to a dedicated user with no shell, confined to a single intake folder, restricted by source address. There is no command to run and nowhere to go. |
| Ransomware deletes the off site copies | The intake folder accepts new files but refuses deletion and renaming, and each archive is individually protected. Enforced by the operating system, not by the application. |
| The application itself is subverted and turns its own protection off | It cannot. It never held the privilege required to change those attributes. |
Two arrangements are supported: one way, shipping to a plain storage machine that need not run GTSuite at all, or mutual, where two installations act as each other's off site vault.
Stated plainly, because a security page should: this protects the copy at rest elsewhere. It does not hide data from an attacker who controls a running server, because at that point the live data is already exposed and the backups add nothing to it. Anyone claiming otherwise is selling you something.
A backup that has never been restored is not a backup
The restore procedure is documented, the private key is held in more than one place in the owner's custody, and a real restore onto a spare database is meant to be exercised on a schedule rather than discovered under pressure. We would rather tell you that now than have you find out later that nobody ever tried.
See the whole picture
The full technical description of the backup design, including the threat model and the operational runbook, is part of the documentation that comes with an account. Confirm an email address and you can read it, alongside a live system you can use and the exercises that show how applications are built.