Tikun 13 Classification: The Operational Guide — Not the Legal One

Israel's Amendment 13 to the Protection of Privacy Law took effect on 14 August 2025. The law defines four security tiers for personal-data databases, mandates different controls per tier, and gives the Privacy Protection Authority the power to impose administrative penalties of hundreds of thousands of shekels or more for non-compliance.

What the law does not say — and what the PPA's professional guide does not say — is which technologies you actually need to deploy.

This guide fills that gap. We won't explain what the law says — the lawyers already did that. We'll explain how to classify the risk tier of your data, what that means in practice for what your organisation must implement, and when you are allowed not to implement — provided you document operational justification.

The guide is written for small and mid-size business owners trying to understand what they must comply with, for CISOs and Data Protection Officers looking for a structured operational framework, and for MSPs and MSSPs advising their clients on Tikun 13 — and occasionally getting tangled up in the same question themselves.

Why the law's what is not the how

The law is written in legal language. It requires "controls appropriate to the risk level of the database." What does that mean?

An attorney will tell you it depends. A regulator will point you to Regulations 5777-2017. A privacy consultant will tell you to run a risk survey. None of them will tell you — deploy EDR, MFA, email security, off-site backup, and a documented permissions policy. That's not their job, and it's not their craft.

That's the job of the operational expert — the MSSP, the CISO, or whoever in the organisation is responsible for translating a regulatory requirement into a working system. And that's exactly where most organisations get stuck.

At Fortress, we work in that translation layer. Our team — GRC, security, SOC and MDR practitioners — built an operational methodology for classifying databases, mapping the required controls, and deciding which technology is realistic for your organisation at each tier. This guide presents that methodology in full.

The four classification tiers — what they mean in practice

The Protection of Privacy Regulations (Data Security), 5777-2017, define four security tiers:

Individual-Managed Database. A database operated by one person plus up to two assistants. Minimal controls, minimal mandatory documentation. Example: a sole-practitioner dentist who manages her patient list herself.

Basic security tier. A standard small-business database with personal data that is not specially-sensitive. Required: a documented information-security procedure, endpoint protection, multi-factor authentication, permission management, basic employee training, backup. Example: an eight-person law firm running a CRM.

Medium security tier. A database containing specially-sensitive information, or a regular database with more than 5,000 data subjects. Required: all Basic-tier controls, plus SIEM, 24-month log retention, vulnerability management, periodic testing, and a database definitions document. Example: a small private health clinic.

High security tier. A database with specially-sensitive information at scale, or with a very large number of data subjects. Required: all Medium-tier controls, plus external penetration testing every 18 months, a 24/7 active SOC, a formal risk survey, and documented vendor controls. Example: a hospital, an insurance company, a bank.

The problem: the regulations tell you what is required, not how to implement it. They also don't tell you what to do when a small organisation cannot operate a 24/7 SOC required by the High tier.

The Fortress classification framework — three questions to a precise tier

Correctly classifying a database starts with three questions, in this order:

Question one: what types of data are in the database?

Tikun 13 defines 12 categories of "specially-sensitive information" that automatically escalate the risk tier, regardless of database size. The categories:

1. Family privacy, intimate life details, sexual orientation
2. Health information (including medical information under the Patient's Rights Law)
3. Genetic information
4. Biometric identifiers used for computerised identification or authentication
5. A person's ethnic origin
6. Criminal record
7. Political opinions, religious beliefs, worldview
8. Professional personality assessments (including assessments of intellectual capacity or job performance)
9. Salary data and financial activity
10. Location and traffic data from a licensed telecommunications carrier
11. Location of a person that reveals one of the categories above
12. Information subject to a statutory duty of confidentiality

The presence of any one of these categories in a database automatically escalates the risk tier.

Important note: "data of minors" does not appear on this list. This is a common error in Hebrew material online. The law addresses minors in other contexts, but not as a standalone category of specially-sensitive information.

Question two: how many data subjects are in the database?

A data subject is a person, not a record. One person with 50 records in a customer database counts as one subject, not 50.

Threshold counts:

• Up to 100,000 subjects, in a database containing only name, address, and contact details — does not qualify as a database under the law. Tikun 13 introduced an explicit exemption for "thin" databases.
• Over 5,000 subjects combined with basic personal information — the threshold to escalate to the Medium tier.
• Over 100,000 subjects with specially-sensitive information — triggers a duty to notify the PPA within 30 days (even if the database is not subject to registration).
• Over 1,000,000 subjects — all penalty amounts are automatically doubled.

Question three: who manages the database?

A database operated by one person plus up to two others falls into the "Individual" tier — minimal controls, but documentation is still mandatory. A database operated within a structured organisation falls into the Basic tier or higher, per the previous questions.

Worked example: classifying three organisations

Organisation A: a 25-person law firm. Operates a CRM with client details, accounts, and active matters. Total data subjects: 8,000.

• Q1 — data types: name, address, contact details, possibly basic financial information. No specially-sensitive categories.
• Q2 — volume: 8,000 subjects.
• Q3 — management: structured organisation, not an individual.

Result: Medium tier (the 5,000 threshold is crossed).

Organisation B: a family medical practice with 6 doctors. Patient management system. Total data subjects: 3,500.

• Q1 — data types: medical information. Yes, specially-sensitive (category 2).
• Q2 — volume: 3,500 subjects.
• Q3 — management: structured organisation.

Result: High tier. Automatic escalation due to the medical-information category.

Organisation C: a sole-practitioner yoga therapist. Manages a list of 200 clients on her own, with contact details and session records.

• Q1 — data types: names, contact details, appointment dates. Possibly general health-status notes.
• Q2 — volume: 200 subjects.
• Q3 — management: individual.

Result: Individual-managed database, escalated to Medium due to the health-related category.

Three organisations, three different tiers. Same framework.

Control mapping — what each tier actually requires

This is where nobody gives you straight answers. The table below translates the regulatory requirements into operational technology categories.

Individual tier. Basic endpoint protection. Strong password and multi-factor authentication on cloud services. Regular backup (at least monthly). Basic processing-activity documentation. No requirement for SIEM, SOC, or formal vulnerability management.

Basic security tier. All of the above, plus:

• Documented database definitions document (Regulation 2)
• Written information-security procedure (Regulation 4)
• Documented permission management with access control (Regulations 8–9)
• Access-logging mechanism by permission (Regulation 10)
• Basic network-connection security (Regulation 14)
• Initial employee training (Regulation 7)
• Information-security incident logging (Regulation 11)

Realistic technology categories at Basic tier: EPP (Endpoint Protection), MFA on all business systems, basic email security, a managed backup solution, a simple identity controls product. Typical monthly spend: ₪50–150 per endpoint.

Medium security tier. All of the above, plus:

• Active SIEM for log collection and correlation (Regulation 11)
• 24-month log retention (Regulations 17–18)
• Documented vulnerability-management process (Regulation 13)
• Periodic excess-data review (Regulation 2)
• Periodic internal audit (Regulation 16)
• Recurring employee training (not just initial)
• Oversight of external service providers (Regulation 15)

Realistic technology categories at Medium tier: everything in Basic, plus a SIEM (which can be managed), a basic MDR solution, an automated vulnerability scanner, and a vendor-management system. Typical monthly spend: ₪150–400 per endpoint.

High security tier. All of the above, plus:

• Comprehensive periodic risk survey (Regulation 5)
• External penetration tests every 18 months (Regulation 5)
• Reporting severe security incidents to the PPA within 72 hours (Regulation 11)
• 24/7 active SOC monitoring (implied by the combination of SIEM and incident-response requirements)
• Independent external audit

Realistic technology categories at High tier: everything in Medium, plus a managed 24/7 SOC, full MDR with automated response, DLP, IRM/DRM for sensitive content, an incident-management (IR) system, and periodic penetration testing. Typical monthly spend: ₪400–1,200 per endpoint.

The operational truth — SMBs can't implement everything

Now to the part no compliance consultant will say out loud.

The family clinic we discussed — six doctors, classified at High tier — cannot realistically operate an internal 24/7 SOC. It doesn't have the budget, the headcount, or the expertise. If the law requires SOC monitoring and the organisation can't build it in-house, what do you do?

The answer is not "break the law." The answer is:

Option 1: outsource to a managed service. SOC-as-a-Service, MDR-as-a-Service, vCISO-as-a-Service. The regulatory requirement is satisfied — the control is active — but you don't have to build it internally. This is the classic case where an organisation pays a monthly fee instead of hiring five security staff.

Option 2: compensating controls. In the rare case where a specific technology isn't applicable, you can document an alternative control that achieves the same purpose. Example: an organisation that can't deploy full DLP can document a strict permissions procedure and role-based access control. This isn't a long-term substitute, but it's sometimes necessary as an interim step. The compensating control must be documented, audited, and actually performed.

Option 3: scope reduction. An organisation can choose to lower a database's classification tier by removing unnecessary specially-sensitive categories. Example: a business that collects date-of-birth without needing it removes the field and lowers the database's risk tier. Removing excess data isn't only an operational saving — it's a standalone regulatory requirement (Regulation 2).

The law doesn't require a 10-person startup to operate an enterprise SOC. It requires the relevant control to be active. How is an operational decision.

The managed services available

The Fortress approach: every regulatory control can be delivered as a managed service. The hard part is deciding what the organisation should buy as a service and what it can build itself.

vCISO-as-a-Service. External Data Protection Officer / CISO, active part-time. Suited to an organisation required to appoint a DPO under Tikun 13 § 17B1 but not needing a full-time CISO. Typical cost: ₪3,000–15,000 per month depending on scope.

GRC-as-a-Service. Preparation of the documents the law requires — database definitions document, information-security procedure, consent documents, data-subject request procedures. Periodic compliance monitoring. Suited to every classification tier. Typical cost: ₪2,000–10,000 per month.

SOC-as-a-Service. 24/7 log monitoring, incident detection, first-line response. Replaces building an internal SOC. Suited to Medium tier and up. Typical cost: ₪50–200 per endpoint per month depending on scale.

MDR-as-a-Service. Active monitoring plus automated response plus full documentation. Combines technology and analysts. Suited to Medium tier and up. Typical cost: ₪80–300 per endpoint per month.

TPRM-as-a-Service. Vendor risk management — periodic checks on external providers that process data, contract documentation, monitoring vendor-side breaches. Suited to organisations with five or more service providers. Typical cost: ₪1,500–5,000 per month.

Some of these services are operated by humans on our side. Some by AI Agents that handle repetitive work automatically (initial incident triage, basic compliance checks, audit-evidence collection). It's a combination — not a substitute.

The MSP/MSSP — the person who actually delivers this to you

Most small and mid-size business owners don't buy these services directly from Fortress or from a single technology vendor. They buy them from an IT and cyber service provider — an MSP or MSSP — who manages their entire technology environment.

For MSPs facing Tikun 13, the challenge is double-edged: understanding what their client needs, and being able to deliver it as a service. Most MSPs are not cyber specialists — they're generalist IT operators. Platforms like Fortress (the Channel Enablement OS) let an MSP operate the full service bundle — vCISO, GRC, SOC, MDR, TPRM — under their own brand, without hiring an internal security team.

This is the classic case where the MSP isn't competing with the Channel Enablement platform — they're using it to deliver deeper service to their clients.

Five common classification mistakes

From hundreds of assessments we've run, these are the five mistakes nearly every organisation makes before producing an orderly classification:

1. "I don't have a database." "I just have a contact form on the website." A contact form that collects name, email, and phone from 100 people a month is a database. If it's stored in an external system, it's a database. If it's emailed and saved there, it's still a database.

2. Missing the escalation from a sensitive category. A database of 1,000 customers is sometimes called "small" — until you notice that one of the order-form questions is "marital status" or "gender." That alone is enough to escalate the classification.

3. Counting records instead of data subjects. A sales database with 100,000 records covering information about 8,000 repeat customers is 8,000 data subjects, not 100,000.

4. Forgetting the employee database. Organisations remember their customer database but forget that the payroll + HR records database is a separate database in its own right — and often in a higher tier because of financial and possibly medical information.

5. Assuming "not subject to registration = not subject to the law." Tikun 13 dramatically narrowed the registration duty. Most databases are no longer required to register. But that doesn't relieve them of every other obligation under the law — the database definitions document, the information-security procedure, the controls under 5777-2017, the notification duty, and data-subject rights. Not registering is not a compliance exemption.

Frequently asked questions

How do I know whether my database requires PPA notification under § 8A(b)?

The notification duty (not registration) applies to databases with more than 100,000 specially-sensitive data subjects, even if the database itself isn't subject to registration. If you have such a database, notify the PPA within 30 days of the condition being met.

Are the Information Security Officer and the DPO the same person?

No. In most cases, they cannot be combined. They are substantively different roles. The DPO is focused on compliance with the law and protection of privacy. The CISO is focused on security technology and bears personal liability under § 17B. Only in very rare cases can the roles be combined, and it is generally not recommended.

If I'm a micro-business with ₪3 million in revenue, do the penalties apply to me in full?

No. Tikun 13 established special caps for small businesses (₪4–10 million revenue) and micro-businesses (revenue up to ₪4 million). In any case, the aggregate financial penalty cannot exceed 5% of annual turnover.

What's the difference between "database owner" and "database controller"?

The old term "database owner" was abolished in Tikun 13 and replaced with "database controller" — aligned with GDPR terminology. The controller is the organisation (not a private individual) that determines the purpose of data processing. This matters both for liability and for who is required by law to appoint a DPO.

What's the difference between registration, notification, and exemption?

Three separate categories:

• Registration duty: Databases held by public bodies, and databases whose main purpose is trading in personal information with more than 10,000 subjects.
• Notification duty: Databases with more than 100,000 specially-sensitive data subjects that are not subject to registration.
• Full exemption: A personal database not used for business purposes, or a "thin" database (name + address + contact details only) with fewer than 100,000 subjects.

If I'm starting to comply now — in 2026 — can I receive any reductions?

Yes. Tikun 13 provides a penalty-reduction mechanism of up to 70% cumulative. The main factors: no prior violation (10–20%), self-stopping and self-reporting (30%), corrective action (20%), DPO appointment when relevant (10%). There are also special caps for small and micro-businesses. The proactive path — reaching compliance ahead of enforcement — has real monetary value.

Can I choose the classification tier of my database myself, or is it set by the PPA?

Classification is the responsibility of the database controller. The PPA does not pre-determine it. But if the classification is wrong — for example, an organisation classified as Basic a database that should have been High — and a breach occurs, the PPA will determine the classification retroactively and calculate the penalty accordingly. Misclassification "downward" is not a defence.

What documents must I keep for review?

The minimum at every tier: a database definitions document (Regulation 2), an information-security procedure (Regulation 4 — mandatory from Basic tier up), confidentiality agreements with employees and vendors, an access-permission register, and information-security-incident logs. At the High tier, also risk-survey results, penetration-test reports, and periodic-audit protocols.

Summary

Tikun 13 puts the organisation in front of a simple operational question: which classification tier am I in, and what must I actually do at each tier?

The classification framework: data types → subject volume → management structure. Automatic escalation in the presence of any of the 12 specially-sensitive categories.

The technology-selection framework: map regulatory controls to operational categories, decide which to build internally and which to buy as a service, and document compensating controls when full implementation isn't feasible.

The compliance framework: active controls > signatures on documents. The PPA checks what's actually in place, not what's written on paper.

If you're not sure which tier you're in — or which mix of in-house controls and managed services is right for your organisation — the Fortress Tikun 13 interactive assessment classifies your databases, identifies the gaps, and builds a tailored action plan. Three minutes, free, no signup required.