Security-tier classification under the Data Security Regulations, walked through

Israel’s Privacy Protection (Data Security) Regulations classify every database holding personal data into one of three security tiers — basic, medium, or high. The tier you land in sets concrete, checkable requirements: a written security policy, access logging, encryption where applicable, and (at the higher tiers) a named security officer and periodic audits. It’s one of the few parts of Israeli privacy law that produces a specific, auditable answer rather than a general principle — and the mechanics are more specific, and less intuitive, than “more sensitive data, more people, higher tier.”

The three tiers

Basic is the default — any database that doesn’t trigger one of the other two. Medium is triggered by what the data is, not by how much of it there is or how many people touch it: the First Schedule lists specific categories — sensitive data types (health, biometric, financial, and others the Regulations enumerate), or the database being owned by a public body, among other conditions. There’s no minimum size for medium tier to apply; one sensitive-data category is enough regardless of scale.

High tier applies to a database that already carries First-Schedule sensitive data, and then crosses either of two independent numeric thresholds in the Second Schedule: 100,000 or more data subjects (the individuals whose data is in the database), or more than 100 authorized users with access to it. Either one alone is sufficient — they’re not two ends of the same dial, they’re two separate triggers, and a database can hit high tier on the access-count threshold while having far fewer than 100,000 data subjects in it.

What actually pushes you into a higher tier

Two different mechanisms, and they’re easy to conflate. Moving from basic to medium is about data category — adding a sensitive data type (health, biometric, financial) crosses that line regardless of size. Moving from medium to high, for a database that’s already medium tier, is about scale — either the data-subject count passing 100,000, or the authorized-user count passing 100. A company can cross the high-tier access threshold without its customer count changing at all, simply by adding vendors or staff with access to an already-sensitive database.

What each tier requires in practice

Every tier requires, at minimum, a defined security policy and a process for identifying who has access. Medium and high tiers add requirements that scale up from there — more frequent risk assessments, stricter access controls, incident logging, and (at high tier) a named person responsible for data security and periodic external review. The Regulations are specific enough that “we have a security policy” isn’t sufficient on its own — the question is whether the policy and controls in place actually match what the tier requires.

Where AI vendor data usually lands

AI vendors affect both triggers. If the data reaching the vendor includes a sensitive category, that alone is enough to put the database at medium tier regardless of how many people or records are involved. From there, adding the vendor’s own personnel as authorized users pushes the access-count toward the 100-user high-tier threshold — a threshold that has nothing to do with how many customers you have. A company that classified its customer database as basic tier two years ago, before adding an AI-enabled support tool with access to that same data, may no longer be operating at the tier it thinks it is — and the reason may be the access count, the data category, or both.

How this fits into an assessment

Tier classification is one of the concrete outputs of a data mapping exercise — not a separate project. Once you know where personal data actually lives and which vendors touch it, the tier for each database follows directly, and so does the gap between what the tier requires and what’s actually in place.