Security that fits how you work.
Your people need the right access. Your customer data needs care. We build both into your system—and keep working on them with you.
The right access. For the right work.
Choose a role and check whether it can access a financial report.
Service team
Working scopeAssigned customers · own branch
A decision you can trace
- Your access checks will appear here.
Sample roles and decisions. Your access rules are defined during setup.
Care for the whole system.
We agree the controls around your data, your team and the way the business operates.
Identity & permissions
Individual accounts, appropriate sign-in checks and access by role, branch or record.
Data & integrations
Configure encryption, private file access and the boundaries between connected services.
Activity & alerts
Record important actions and route agreed warning signals to someone responsible.
Backups & recovery
Agree backup retention and recovery targets, then test the restore process.
Privacy controls
Build consent, retention and data-request workflows around the requirements you agree with your advisers.
Boundaries for AI
Limit what agents can read or change, with human approval for sensitive actions.
In depth
What the system has to provide
Your clients' data. Protected properly.
What "business data security" means when you hold client data
Business data security does not start with a tool you install. It starts with how the system is built: who is permitted to see which field, what happens to the data in transit and at rest, and who did what and when. Those three questions are answered at the level of the system, not at the level of the workstation where ordinary defences like antivirus and firewalls operate.
Ten tools — ten places your data lives
A business running client data across ten separate tools holds ten permission models and ten audit logs, each with its own vendor and its own rules. The real problem sits between the tools: in the integration, in the export, in the copy no tool owns. The answer is not another layer of defence. It is fewer tools.
Three layers: role-based permissions, encryption, audit log
Permissions built around the role rather than the person. Encryption covering data in transit, at rest and in backups alike. An audit log that records refused access attempts, not only approved ones. All three are settled at the architecture stage, not added once the system already exists.
Data security for small businesses: what is needed with no IT department
A business without an IT department needs the system itself to do the work: permissions that update themselves when a role changes, logging that writes without being reminded, a backup that runs on its own. That leaves the owner two decisions: who gets which permission, and who is alerted when something falls outside it.
Scenarios that actually happen: a departure, a lost device, a vendor holding a backup
An employee leaves: permissions close in a single action, not in a checklist someone has to remember. A device is lost: the session is revoked remotely and the window into the system shuts. An external vendor was granted access: it is clear exactly what they hold, and for how long. These are set out in full — including what counts as a serious security incident and what has to be reported — in the article on [a data breach](/en/blog/data-breach-suspicion).
What happens when a client asks you to delete their data
You locate every place the data appears, delete what can be deleted, and record what was retained and under which obligation — accounting records kept for a statutory period, for instance. What the system has to provide is not a delete button. It is an accurate map of the data.
Regulation: what is required of the system
The Israeli Privacy Protection (Data Security) Regulations, 5777-2017 set requirements for access permissions, automatic logging, encryption, and data security when work is outsourced; for clients in the European Union the GDPR sets the equivalent. This is not legal advice. What can be said with confidence is that the system has to provide the ability to prove, not merely good intentions.
Why this is not something you bolt on at the end
Adding role-based permissions to a system built without a role model means touching very nearly every screen in it. In a system built with that separation from day one, a change in the business — a new role, another branch — rolls in without becoming a project of its own.
An alert needs an owner.
A lost device, an unexpected export or an unusual sign-in needs a clear response. We agree who acts and how you’re kept informed.
Review the signal
Check the context and recent activity to understand what happened.
Contain the issue
Restrict affected access and coordinate the next steps with your team.
Follow through
Verify the fix, record the findings and improve the relevant controls.
Kept up to date. Kept in view.
New staff, new integrations, new AI capabilities. We revisit access, maintain dependencies and propose security improvements as your system evolves.
How we work togetherClear expectations, from the start.
Let’s look after what your business runs on.
Tell us about your system, your team and the information they work with.
Let’s talkChat on WhatsApp