Most owners believe their company is covered: the hosting provider runs backups, the IT person controls access, and an incident plan exists somewhere. In practice, these three areas hide the most expensive assumptions a company can carry. This article separates the myths from the reality, and shows what hosting and domains really cover, how access should be structured, and what an incident plan must contain to be useful. Appjad (أبجد) works with owners across the Gulf on exactly these questions, and the pattern is consistent: the gap is rarely technology, it is ownership.
Key takeaways
- A backup you have never restored is a hope, not a backup.
- Access control is about who can do what, not who has a password.
- An incident plan is a short list of decisions and names, not a document.
- Test all three on a normal day, not during the crisis.
Myth: the hosting provider backs up your data
Hosting providers usually back up the server, not your business. They restore a machine; they do not restore your database, your files, your configurations or your integrations. When a provider does offer backups, retention windows are often short and restores are slow.
The reality is that backup ownership sits with you. Ask three questions in writing: what exactly is backed up, how often, where it is stored, and how long a restore takes. Then run a restore test on a copy, not on the live system.
- List every system that holds business data: website, store, CRM, accounting, email, shared drives.
- For each, name who owns the backup and where the copy lives.
- Restore one system to a test environment and check that it actually works.
- Record the result and the date, and repeat on a schedule.
If nobody can answer these questions, that is the finding. Appjad builds this into the handover of every system it delivers, because a backup nobody has tested is a promise, not protection.
Myth: access control means strong passwords
Strong passwords matter, but they are the floor, not the ceiling. Access control answers a different question: who is allowed to do what, and who approved it. A shared admin login with a strong password is still a shared login, and when something goes wrong nobody can tell who did it.
The reality is role-based access. Each person gets their own account, the permissions their job requires, and nothing more. Departures and role changes trigger an immediate review.
- List your systems and the roles that touch each one.
- Define the minimum permission each role needs to do the job.
- Remove shared accounts and generic logins, starting with admin access.
- Review the access list quarterly and after every staff change.
- Keep an owner-level account that is not used daily, held securely.
This is the same principle behind data protection myths about access: the risk is rarely the outsider guessing a password, it is the insider with more access than the job requires.
Myth: an incident plan is a document for large companies
Small and mid-size companies often skip incident planning because it sounds bureaucratic. Then a laptop is stolen, an account is compromised, or a staff member deletes the wrong folder, and the first hour is spent deciding who to call.
The reality is that an incident plan is short. It names the person who decides, the first three actions, and how customers and staff are told. It fits on one page and is reviewed twice a year.
The most valuable incident plan is the one your team can follow at 11pm without calling you.
- Name one incident owner and one backup.
- Write the first three actions for the most likely scenarios: lost device, compromised account, deleted data, failed system.
- Keep contact details for your hosting, domain and key vendors in one place offline.
- Decide in advance who speaks to customers and in what tone.
Appjad helps owners turn this into a working routine rather than a document that sits unread, and pairs it with the recovery file described in building an owner's recovery file.
Myth: testing is only for technical teams
Owners often assume testing belongs to IT. But the tests that matter most are business tests: can we restore the store and take an order, can we access the CRM after a role change, can a new staff member follow the incident page without help.
The reality is that these tests take an afternoon and reveal more than any technical report. Run them on a normal working day, not during a crisis, and write down what failed.
- Restore a copy of the store and place a test order end to end.
- Remove a test user's access and confirm they are locked out everywhere.
- Give the incident page to someone who has never seen it and watch where they hesitate.
- Fix the gaps and set a date to repeat the test.
Each test produces a short list of fixes. That list is your real security roadmap, and it is more useful than any generic checklist.
Myth: this is a one-time project
Security work is often treated as a project with a start and an end. In reality, systems change, staff change, and new tools are added, and each change quietly reopens the gaps you closed.
The practical answer is a short operating rhythm. Once a quarter, review access, run one restore test, and update the incident page. Once a year, review the whole picture with your team and your technology partner.
Appjad designs this rhythm into the systems it builds, so the company keeps control after launch rather than depending on one person's memory. The same discipline applies to any new tool your team adopts.
Frequently asked questions
How often should we test a restore?
At least once a quarter for the systems that carry revenue, such as the store, CRM and accounting. Test on a copy, record the result, and fix anything that fails before the next quarter.
Who should own access control in a small company?
One named person, usually the operations or IT lead, with the owner holding a separate account for oversight. The point is that a single person is accountable and reviews the list on a schedule.
What belongs in a one-page incident plan?
The incident owner and backup, the first three actions per scenario, vendor contacts, and who speaks to customers. Keep it offline and review it twice a year.
Next step: test one thing this week
You do not need a full programme to start. Pick one system that carries revenue, restore a copy, and confirm it works. Then review who has admin access and remove one unnecessary account. If you want this built into your systems properly, talk to Appjad (ابجد) about a short security and governance review, and let the company's own systems carry the discipline instead of one person's memory.
