Data Leak: What Your System Needs to Know Before It Happens
Most public discussion of data leaks starts after it's already happened, a headline, an exposed database, millions of records.
That discussion is interesting but not useful by the time it gets there. The decisions that determined whether the incident would even be discovered had already been made, usually years earlier.
This article is about those decisions, not about crisis management, and not about the tools you install afterward. The question that interests us is one: what does the system need to allow before something happens.
What is a data leak, and why the definition is broader than it seems
In Hebrew several terms are used for the same thing: data leak, information seepage, data spill, data breach.
The shared meaning is simple: information that reached someone not authorized to see it, by mistake or on purpose.
Notice what's missing from that definition: no hacker, no breach-in, no malware.
That's the point most content on this topic misses. Search for "data leak" and you mostly get two kinds of results: articles about major incidents, and vendors selling monitoring tools. Both assume the threat comes from outside.
In practice, in a business that manages information for clients, a large share of incidents look completely different. An employee who exported a file before leaving. A vendor who received a backup and never deleted it. An account that stayed open after someone changed roles.
None of these would be stopped by antivirus software, because none of them is malicious code. All of them are technically authorized access that shouldn't have been authorized.
That's the distinction that determines where you look for a solution: against malicious code you defend, against excess permission you design, and the answer sits in architecture, not in a product list.
One more point worth sharpening: security incidents aren't always leak incidents. Sometimes information never left anywhere, but someone altered it, deleted it, or accessed it beyond their permission. Those are incidents too, and they also require the system to be able to tell you what happened.
That's a question of architecture, not of defense. The difference isn't semantic, it determines where the solution lives.
A defense tool sits on top of the infrastructure and inspects traffic. Architecture determines what can be requested at all, by whom, and what gets logged when someone asks.
Most leaks aren't a breach, they're a permission
A service business typically runs a long list of separate systems: CRM, calendar, spreadsheets, WhatsApp, accounting software, cloud storage.
Each one holds a copy of the information, and each has its own permission model. That creates a situation that's hard to call "control." No one can say, without checking, who exactly can see customer details today.
And when no one knows who can see what, no one knows when someone saw something they shouldn't have.
Here are three patterns that repeat themselves:
A permission that stayed
An employee moved from role to role. Permissions in one tool were updated. In three others they stayed as they were. No one did anything wrong, and yet there's now a person who can see information unrelated to their role.
A copy that got out
Someone exported a spreadsheet to work on it comfortably, emailed it to themselves, and forgot about it. The file now lives somewhere no one is counting.
A vendor who held onto data
A campaign manager who received a leads list. A former developer who kept a copy of the database. A service provider that shut down and no one asked what happened to the data they held.
None of these three cases is an attack. All of them are the result of scattered architecture.
The Privacy Protection Regulations (Data Security), 5777-2017, which took effect in May 2018, explicitly address outsourcing and require an advance review of information-security risks in any engagement, plus an explicit contractual framework. That requirement exists because the legislator identified exactly this third pattern.
There's also a human side that's easy to overlook. When an employee needs four screens to handle one customer, they create shortcuts: exporting a file to work on it comfortably, sending a list over WhatsApp to save time, sharing a password because it's faster.
None of these acts is malicious. All of them are a direct result of architecture that forces jumping between tools, and each one creates another copy of the data somewhere no one is monitoring.
The right approach to the number of copies is to reduce them, not to monitor them. The fewer places hold the data, the fewer places you need to track, and that's also why we build one system instead of connecting ten disconnected ones to each other.
What the system needs to be able to tell you
Say a suspicion comes up: someone raised an eyebrow, a client reported something odd, or an inquiry came in.
The first question isn't who's to blame, it's what exactly was exposed. Without an answer to that, every next step is a guess: you can't assess scope, you can't decide on reporting, and you can't tell the client what happened to their data.
The answer depends on one thing: whether the system logged it.
Regulation 10 of the regulations defines what's required of a logging mechanism in a database subject to a medium or high security level. According to the guide published by the Privacy Protection Authority, the mechanism needs to include the user's identity, the date and time of the access attempt, the system component that was accessed, the type of access, read, write, or query, its scope, and whether access was approved or denied. The requirement applies both to human access and to access performed by a piece of code.
Notice two things in that list:
First: reads, not just writes and deletions. Most systems businesses use log changes and don't log views, convenient for the developer, useless for an investigation. If an employee opened three hundred customer files in the past week without changing any of them, a system that only logs changes will show nothing at all.
Second: denied attempts. A log that only records what succeeded tells half the story. A log that also records what was blocked shows a pattern.
Third: retention, how long the logs are kept, and who can touch them.
Three security layers are permissions, encryption, and logging. The third is the one that determines whether you'll know what happened, and it's the only one you can't add retroactively, a log can't be created after the fact.
A log that gets auto-deleted after a short period won't help with an incident that's discovered late, and quite a few security incidents are discovered exactly that way. A log the system admin can edit isn't evidence. Both of these points need to be closed at the design stage, not in response to a question from an accountant or a lawyer.
What counts as a severe security incident
Here's a detail that changes the whole picture, and it comes straight from the Privacy Protection Authority's guide.
A severe security incident is defined, among other things, as an incident in which a database saw unauthorized use of information, or use beyond permission, or in which the integrity of the information was harmed.
Businesses tend to assume an incident means theft. In practice the definition is broader.
And here's the part most businesses don't know: the Authority clarifies that "use" is defined under the Privacy Protection Law to also include disclosure, transfer, and delivery. In other words, even if someone only viewed the database and took no other active action like copying, it counts as an incident.
Pause on the systemic implication of that: if mere viewing counts, then a system that only logs changes won't be able to identify such an incident, and won't be able to rule it out either.
That's the difference between saying "we checked, and no action was taken" and saying "we checked, and no one accessed those records." The first doesn't actually answer the question. The second does.
This is one of the first decisions that needs to be made at the architecture stage, not something you add once a need arises. Logging reads has a cost in performance and storage, so whoever doesn't decide on it upfront usually never adds it later.
There's also a flip side worth stating. Full logging of reads isn't free, and it isn't required in every system or at every sensitivity level. The decision follows from the type and scope of the data, and that's exactly the kind of decision made in a conversation with an engineer, not by picking from a vendor's feature list.
Reporting a security incident: what the system needs to provide
Let's be clear upfront: this isn't legal advice, and we're not lawyers. A real incident requires legal counsel, not an article.
What we can say is what's required at the system level.
Regulation 11(d) of the regulations states that in the event of a severe security incident, the owner of a database subject to a medium or high security level must notify the Registrar immediately, and must also report the steps taken following the incident.
A point worth sharpening: enforcement by the Authority has grown stricter in recent years, and the current prevailing interpretation is that reporting is required immediately, with no defined time window. Any specific figures you find in older articles should be checked with a lawyer before relying on them, this is an area where the policy keeps shifting.
What is clear at the system level: immediate reporting requires immediate information.
If you were asked tomorrow to describe exactly what was exposed, how long would it take you to put together the answer?
You can't report scope without knowing what was exposed. You can't report steps taken without having taken them, and you can't take them quickly if revoking access requires moving across ten different tools.
The regulations also require the security procedure to include instructions for handling security incidents by severity, including revoking access and other immediate steps. A procedure is a document. What makes it actually executable is the system.
A business whose procedure says "access is revoked immediately," while its systems are scattered across ten tools, has written a procedure it can't actually fulfill.
Another point directly tied to the system: who discovers that there's an incident, and how. A business that waits for a client to complain finds out late. A business with alerts defined for anomalies finds out earlier, and that gap is usually the difference between a contained incident and one that spreads.
The operations panel is the channel this runs through for us: reporting a fault or suspicion directly over WhatsApp, opening a ticket at any hour, and a repeated alert on every change that gets deployed.
Three scenarios, and what each one requires from the architecture
An employee who left
The most common pattern, and the least dramatic. What's required: closing all permissions in one action, revoking sessions and tokens, and the ability to pull up their activity list from the recent period.
In most cases there's no malicious intent here, just a file that got exported and stayed around, and an account that stayed open because no one remembered it. The problem isn't the person, it's the lack of a single point of control: closing access should be a single action, because there should only be one place where access was granted in the first place.
A lost device
A forgotten laptop, a stolen phone. When the data sits on the device, that's a problem. When the device is only a window into the system, you revoke the session remotely and the window closes.
The regulations explicitly address mobile devices and the risk that data may leak through them, or that connecting them may harm the systems of the database. The decision to keep data in the system rather than on the endpoint is directly tied to this point.
Worth being precise: this doesn't solve everything. Remote session revocation is a capability you build, not a feature that exists on its own. This decision looks technical at the design stage and turns out to be essential the moment something happens, which is why it's made in advance, before you know whether it will ever be needed.
Internal access that shouldn't have happened
This is the most sensitive scenario, and in some industries the most dangerous one too. At a law firm, for example, not every lawyer should be able to see every case file. Restricting access between case files isn't just a procedure, it's a system-level requirement. A law firm management system built correctly enforces that separation at the data level, not by hiding buttons on a screen.
The difference matters: hiding an interface prevents mistakes. Enforcement at the query level prevents access, and also generates a log when someone tried.
The same logic applies to a clinic where one therapist shouldn't see another's case files, and to an insurance agency where one agent shouldn't see another agent's client file. The industry changes, the system-level logic stays the same.
Why prevention is a design decision, not a tool purchase
The market sells information security as a layer. You install it, configure it, pay monthly. That works when you're protecting infrastructure against malicious code. It doesn't work when the question is who inside the organization can see what.
Role-based permissions require a role model, and building that model requires understanding who does what in the business. You acquire that understanding during the mapping stage.
A custom-built CRM system built this way comes with one permission model, one log, and one boundary around the data. Fewer points of failure, and fewer places you need to track.
The regulations add another point that's easy to miss: they require a periodic discussion of security incidents and a review of whether the security procedure needs updating. A discussion like that requires material to work from. A business without organized logs shows up to that discussion with no data.
The practical implication is about speed. When the permission model is part of the system, a change in a business process flows into it automatically. A new role gets added, a new branch opens, a department splits. For us, all of that is handled within the retainer, no new quote, no separate project.
Frequently asked questions
What's the difference between a data leak and a security incident?
A data leak is an everyday term describing a situation where information reached someone unauthorized. A security incident is the term used in the regulations, and it's broader, it also includes situations where information was used beyond permission, or where the integrity of the data was harmed, even if nothing ever left the organization.
Does viewing information without copying it count as an incident?
According to the Privacy Protection Authority's guide, yes. "Use" is defined under the law to also include disclosure, transfer, and delivery, so even someone who only viewed the database without taking any further action falls under the definition. The systemic implication is that logging that only records changes won't identify this kind of incident.
How much time do you have to report a severe security incident?
The regulations require immediate reporting to the Registrar, alongside reporting the steps taken. This is a topic that requires legal counsel, not a determination from an article. Enforcement has grown stricter in recent years, and it's worth checking any specific timeframe you come across in older sources with a lawyer.
How do you even know an incident happened?
In some cases someone reports it. In others, no one does, and then discovery depends on two things: logs that record both reads and denied attempts, and alerts pre-configured for anomalies. Security incidents discovered late are usually incidents the system simply wasn't built to detect in the first place.
Who needs to know there's an incident, and when?
At the system level, the first question is who in the organization gets notified when something deviates, who gets the notification, on what channel, and for which types of incidents. At alcyone14, alerts arrive over WhatsApp, and don't wait for someone to log into the system.
Do we need a DLP system?
That's a legitimate question, and the answer depends on scope and industry. DLP monitors data movement outward, but it doesn't determine who inside the organization is allowed to see what in the first place, that's a separate layer, one that's set at the architecture level.
What happens to data that's already sitting in our old tools?
The mapping stage includes checking every tool and the data sitting inside each one. The migration happens in stages, and each stage is verified before moving on. A tool that isn't deliberately shut down stays a place where the data keeps living, which is why closing it out is part of the process, not an afterthought.
Did Amendment 13 change anything at the system level?
Amendment 13 to the Privacy Protection Law took effect on August 14, 2025, and expanded the Authority's oversight and enforcement powers. The practical implication at the system level is that the ability to prove things has become more important. A business that can produce organized logs is in a different position than a business that says it's sure everything is fine. The legal implications are a matter for legal counsel.
Do you handle the incident if it happens?
Not in the sense of cyber forensics or crisis management, that's a different field, requiring professionals whose job that is. What alcyone14 does do is make sure the system can provide what's needed: who accessed it, when, why, and exactly what was exposed.
Ready to know what your system actually logs?
A data leak doesn't start on the day it's discovered. It starts on the day someone decided which fields the system records.
Our first conversation is a mapping session, by the end of it you'll know how many copies of your data exist, who touches them, and what your system will be able to tell you if a suspicion ever comes up.
At alcyone14, the number of clients we take on at once is deliberately limited. One engineer who knows the business in depth, not an account manager, not a communications layer, this is a partnership.