Permissions and Backups in a Business System: What Owners Should Be Able to Verify

Two questions are enough to tell whether a system is governed or just switched on: who sees what, and how much work is lost if the system isn't there tomorrow morning. These are owner questions, not technical ones, and they need to be asked before signing, because afterward they turn into change requests that need a quote.

Verifying them doesn't require IT skills. It requires two documents anyone can read: a table of who can do what, and the record of a successfully completed restore test.

Permissions Aren't About Trust

The most common objection is that everyone in the company is trusted. The point is a different one: permissions limit the damage from mistakes, stolen credentials, and poorly managed departures, and they make it possible to trace who made a change. An honest person who clicks the wrong row can delete a year's worth of records just as easily as a dishonest one.

• A permission is granted for the activity, not for the person. When a job changes, the role changes too, instead of adding an exception.
• Viewing, editing, deleting, and exporting are different actions. Exporting is the one that gets forgotten, and it's the one through which data actually leaves the company.
• Some data isn't needed by those who don't need it: purchase costs, margins, personnel data, confidential terms agreed with individual customers.

The Roles-and-Actions Matrix

This is the document that makes the discussion concrete. It's written with the managers and then handed to the vendor to implement, not the other way around. Illustrative example for a company with warehouse, sales, and administration.

The column that really matters is the last one. Listing what a role must not be able to do forces a decision; the list of what it can do, on its own, tends to grow until it stops meaning anything.

Onboarding, Transfer, Offboarding: The Cycle No One Governs

Permissions don't go bad on day one. They go bad over three years, one exception at a time.

1. Onboarding: the person receives the role they're meant to have, not a copy of a colleague's account. Copying an account is the fastest way to propagate privileges no one ever decided on.
2. Job change: the old role is removed and the new one granted. Adding the two together is the main cause of accumulated permissions.
3. Substitutions and delegations: they need a written end date, or they stay in place forever.
4. Offboarding: access is closed the same day, and the list also needs to include email, shared archives, devices, and accounts on external services.

Backups: Two Numbers to Agree On, Not a Reassurance

The answer to "do you have backups?" is always yes. The useful question has two parts, and both are your decisions before they're technical ones.

• How much work you can afford to lose. If the backup runs overnight, a failure at 5 p.m. costs a full day's worth of entries. If a full day is unsustainable, the frequency needs to increase, and that has a cost to weigh against the cost of the loss.
• How long you can afford to be down. Getting a system back up takes hours, not minutes, and how long depends on how much preparation was done in advance.

Both values need to be written into the contract along with what they cover. An illustrative example, with numbers to be decided case by case: daily backups kept for a few weeks, a periodic backup kept longer, and at least one copy in a different location that isn't reachable with the same credentials as the systems in use.

• What gets backed up: the database, but also attachments, generated documents, configurations, and customizations. Restoring just the database can leave out years of documents.
• Who checks that the backups actually run, and who gets notified when they fail. A backup that fails silently is the most common situation and the most dangerous.
• Who can access the backups: they contain the same data as the system, with the same confidentiality obligations.

An Untested Restore Doesn't Exist

The only proof that a backup works is having actually restored it. The test is run on a separate environment, with demo data or with a copy, and it's put in writing. That record is the document you can ask for every year without having to discuss technology.

1. Date of the test, who ran it, and which backup was used.
2. What was restored: system, database, attachments, configurations.
3. How long it took, from the go-ahead to the system being usable again.
4. What was checked afterward: a few documents opened, some records checked, a printout produced, a login tested with a normal user.
5. What didn't work and how it was fixed. A first test with no problems found at all has usually been done too easily.

What Can't Be Promised

No vendor can guarantee that a system will never be breached or that data will never be lost. Anyone who promises that is selling peace of mind, not security.

What This Guide Doesn't Cover

This guide covers verifiable requirements around access and recovery: no absolute security guarantee and no compliance statement. The functional tests to run before putting software into use — verifying it does what's needed on real cases — are a different matter and come first. How to avoid being locked into a single vendor, with data and credentials that need to stay yours, also deserves its own discussion.