Privacy Protection Law
The full text of Israel's Privacy Protection Law, 5741-1981 · the principles under which these Regulations were made.
Read moreIsrael's Protection of Privacy (Data Security) Regulations, 5777-2017Security levels · the database definitions document · access control · security incidents · audits
The verbatim Hebrew of each key regulation, topic by topic · and, right beside it, an unofficial English translation and a plain-English explanation with an example. See exactly what the Regulations say, and what that means in practice for anyone managing a database in Israel.
Manpower license #1565 Regulation text from Nevo Official sources
3 security levelsBasic · medium · high
The statute textHebrew original is binding
Verbatim Hebrew of the Regulations · the Hebrew original is legally bindingEach orange box below reproduces the exact Hebrew text of the regulation, word for word, cross-checked against the official version on Nevo. Beside it we give an unofficial English translation for convenience only, and the teal boxes are our own plain-English explanation and are not part of the Regulations. The single binding version is the Hebrew as published in the Official Gazette (Reshumot); where the translation and the Hebrew differ, the Hebrew prevails.
Hebrewthe binding text
Official Hebrew · Nevo
Privacy Protection Authority
AI summary · Israel's Data Security RegulationsClick to read the page summary
The Protection of Privacy (Data Security) Regulations, 5777-2017 ("תקנות הגנת הפרטיות ("אבטחת מידע"), התשע״ז-2017") were made under the Protection of Privacy Law, 5741-1981 ("חוק הגנת הפרטיות, התשמ״א-1981") and set practical data-security duties for anyone who manages a database. The core: three security levels (basic, medium, high · regulation 1) derived from the characteristics of the database; the database definitions document (regulation 2); access-permission management by role (regulation 8); documenting and handling security incidents with immediate notice to the Registrar of a serious incident (regulation 11); and periodic audits once every 24 months (regulation 16). Below · the verbatim Hebrew of each key regulation, an unofficial English translation, a plain-English explanation, two worked examples and a short knowledge check.
Official Hebrew · Nevo
Privacy Protection Authority
Privacy Protection Law · NETO
NETO privacy policy
- Security levels · basic, medium and high, by the characteristics of the database (regulation 1).
- Database definitions document · mapping the information, purposes and risks (regulation 2).
- Access control · permission by role and to the extent required only (regulation 8).
- Security incidents · documentation, handling · and immediate notice to the Registrar of a serious incident (regulation 11).
- Audits · once every 24 months for a medium or high database (regulation 16).
- The binding text is the Hebrew published in Reshumot · this page shows the quote next to an explanation.
Quick navigation
Background
What are the Data Security Regulations?
The Protection of Privacy Law, 5741-1981 sets the principles · and the regulations made under it turn them into practical duties. The Protection of Privacy (Data Security) Regulations, 5777-2017, are the central regulations in the field: they apply to anyone who manages a database in Israel and set out exactly what must be done to secure it.
On this page, for each key topic, we first give an unofficial English translation of the regulation, and right beside it the verbatim Hebrew of the regulation (in the orange box), followed by a plain-English explanation with an example (the teal box). This is especially relevant to employers · including foreign companies hiring Israeli workers through an Employer of Record · who hold employees' personal data. As the legal employer, NETO manages that personal data in line with the Law and these Regulations on the client's behalf · access control, incident handling and respecting data-subject rights. See also our privacy policy.
- Three security levels · with duties that grow as the level rises
- Mapping, documentation and access control · in writing and in order
- Handling security incidents · and notifying the Registrar of a serious one
Made under the 1981 LawSection 36 of the Law
Legal notice: the content of this page is general information and accessibility only and is not legal advice and must not be relied on as such. The binding text of the Regulations is the version published in the Official Gazette (Reshumot), as it appears in the official databases (Reshumot · Nevo). Later amendments and updates are possible. Before any decision or action, consult the up-to-date text and a qualified lawyer.
The Data Security Regulations · in numbers
Security levels
3 Basic · medium · high · regulation 1
The level is derived from the characteristics of the database under the First and Second Schedules.
High level
100,000 data subjects or more · Second Schedule
Or more than 100 authorised persons in the database · then the high level applies.
Periodic audit
24 months · regulation 16
In a medium or high database · an internal or external audit at least once every 24 months.
Serious incident
Immediate notice to the Registrar · regulation 11
The database owner notifies the Registrar immediately and reports on the steps taken.
Security levels · basic, medium and high
The Regulations do not impose the same burden on every database. Regulation 1 defines three security levels, and the level is set by the characteristics of the database · under the First and Second Schedules.
Regulation 1 · Definitions (the security levels)
Unofficial English translation
"Databases subject to the basic security level" – databases that are not of the types listed in the First or Second Schedule and are not a database managed by an individual;
"Databases subject to the medium security level" – databases of the types listed in the First Schedule that are not a database managed by an individual;
"Databases subject to the high security level" – databases of the types listed in the Second Schedule;
Binding text · Hebrew original (Reshumot / Nevo)
”מאגרים שחלה עליהם רמת האבטחה הבסיסית“ – מאגרי מידע שאינם מן הסוגים המפורטים בתוספת הראשונה או השנייה ואינם מאגר המנוהל בידי יחיד;
”מאגרים שחלה עליהם רמת האבטחה הבינונית“ – מאגרי מידע מן הסוגים המפורטים בתוספת הראשונה ואינם מאגר המנוהל בידי יחיד;
”מאגרים שחלה עליהם רמת האבטחה הגבוהה“ – מאגרי מידע מן הסוגים המפורטים בתוספת השנייה;
Second Schedule · the high security level
Unofficial English translation
Databases subject to the high security level –
(1) a database as referred to in item 1(1) or (3) of the First Schedule, including a database of a public body within the meaning of section 23(1) of the Law that meets what is stated in items (1) or (3), which contains information about 100,000 people or more;
(2) a database as referred to in item 1(1) or (3) of the First Schedule, including a database of a public body within the meaning of section 23(1) of the Law that meets what is stated in items (1) or (3), in which the number of authorised persons exceeds 100.
Binding text · Hebrew original (Reshumot / Nevo)
מאגרי מידע שחלה עליהם רמת האבטחה הגבוהה –
(1) מאגר מידע כאמור בפרט 1(1) או (3) בתוספת הראשונה, לרבות מאגר של גוף ציבורי כמשמעותו בסעיף 23(1) לחוק המקיים את האמור בפרטים (1) או (3), שיש בו מידע על אודות 100,000 אנשים ומעלה;
(2) מאגר מידע כאמור בפרט 1(1) או (3) בתוספת הראשונה, לרבות מאגר של גוף ציבורי כמשמעותו בסעיף 23(1) לחוק המקיים את האמור בפרטים (1) או (3), שמספר בעלי ההרשאה בו עולה על 100.
Explanation · not part of the RegulationsThere are three levels. Basic · the default, for any database that does not fall within the Schedules and is not managed by an individual. Medium · databases in the First Schedule, for example a database whose purpose is delivering information to another, a database of a public body, or one that includes sensitive information (medical, financial, political, biometric and more). High · a database of those types that also contains information about 100,000 people or more, or that has more than 100 authorised persons. As the level rises, more duties are added · a detailed security procedure, identification and authentication, access control, audits, and in a high database also a risk survey and penetration tests.
Example: the customer database of a marketing firm that sells mailing lists already falls within the medium level · even if it is small. If it grows beyond 100,000 people · it moves up to the high level, with all the added duties.
The database definitions document · the foundation for security
Before you can secure a database you have to know what is in it. Regulation 2 requires every owner to prepare a document mapping the information, the purposes, the risks and the people responsible.
Regulation 2 · the database definitions document
Unofficial English translation
(a) A database owner shall define, in a database definitions document (hereinafter – the database definitions document), at least all of the following matters:
(1) a general description of the collection and use operations of the information;
(2) a description of the purposes of using the information;
(3) the various types of information contained in the database, having regard to the list of information types in item 1(3) of the First Schedule;
(4) particulars of any transfer of the database, or a substantial part of it, outside the borders of the State, or use of the information outside the borders of the State, the purpose of the transfer, the destination country, the manner of transfer and the identity of the transferee;
(5) information-processing operations carried out through a holder;
(6) the main risks of harm to the security of the information, and the manner of dealing with them;
(7) the name of the database manager, of the holder of the database and of the person in charge of information security in it, if such a person has been appointed.
(b) A database owner shall update the database definitions document whenever a significant change is made to the matters listed in sub-regulation (a), and shall examine the need for such an update, on account of technological or organisational changes or security incidents as referred to in regulation 11, each year by 31 December.
(c) A database owner shall examine, once a year, whether the information it keeps in the database is not more than is required for the purposes of the database.
Binding text · Hebrew original (Reshumot / Nevo)
(א) בעל מאגר מידע יגדיר במסמך הגדרות מאגר (להלן – מסמך הגדרות המאגר), את כל העניינים האלה לפחות:
(1) תיאור כללי של פעולות האיסוף והשימוש במידע;
(2) תיאור מטרות השימוש במידע;
(3) סוגי המידע השונים הכלולים במאגר המידע, בשים לב לרשימת סוגי המידע שבפרט 1(3) בתוספת הראשונה;
(4) פרטים על העברת מאגר המידע, או חלק מהותי ממנו אל מחוץ לגבולות המדינה או שימוש במידע מחוץ לגבולות המדינה, מטרת ההעברה, ארץ היעד, אופן ההעברה וזהות הנעבר;
(5) פעולות עיבוד מידע באמצעות מחזיק;
(6) הסיכונים העיקריים של פגיעה באבטחת המידע, ואופן ההתמודדות עמם;
(7) שמו של מנהל מאגר המידע, של מחזיק המאגר ושל הממונה על אבטחת מידע בו, אם מונה כזה.
(ב) בעל מאגר מידע יעדכן את מסמך הגדרות המאגר בכל עת שנעשה שינוי משמעותי בנושאים המפורטים בתקנת משנה (א), ויבחן את הצורך בעדכון כאמור, בשל שינויים טכנולוגיים ארגוניים או אירועי אבטחה כאמור בתקנה 11, בכל שנה עד 31 בדצמבר.
(ג) בעל מאגר מידע יבחן, אחת לשנה, אם אין המידע שהוא שומר במאגר רב מן הנדרש למטרות המאגר.
Explanation · not part of the RegulationsThe database definitions document is the database's identity card · it brings together in one place what information is collected, why, which types of information there are (and especially sensitive information), whether information is transferred abroad, who processes it, the main risks and who is responsible. You do not need technology to begin · you first have to think and write. Sub-paragraph (c) adds an important principle · once a year you check that you are not keeping unnecessary information (data minimisation).
Example: an employer managing an employee database will record in the document: the information is collected for paying wages and managing the employment, includes salary data and bank accounts, is processed by an external payroll bureau, and the main risk is a leak of salary data · addressed by encryption and restricted permissions.
Access-permission management · who sees what
One of the central principles of data security · not everyone who works in an organisation needs access to all the information. Regulation 8 requires access to be granted by role, and only to the extent required.
Regulation 8 · managing access permissions
Unofficial English translation
(a) A database owner shall set the access permissions of authorised persons to the database and to the database systems, in accordance with job definitions; the access permission for each role shall be to the extent required for the performance of the role only.
(b) A database owner shall maintain an up-to-date record of roles, the access permissions granted to them, and the authorised persons filling those roles (hereinafter – the list of valid permissions).
Binding text · Hebrew original (Reshumot / Nevo)
(א) בעל מאגר מידע יקבע הרשאות גישה של בעלי הרשאות למאגר המידע ולמערכות המאגר, בהתאם להגדרות תפקיד; הרשאת הגישה לכל תפקיד תהיה במידה הנדרשת לביצוע התפקיד בלבד.
(ב) בעל מאגר מידע ינהל רישום מעודכן של תפקידים, הרשאות הגישה שניתנו להם, ושל בעלי ההרשאות הממלאים תפקידים אלה (להלן – רשימת ההרשאות התקפות).
Explanation · not part of the RegulationsAccess is set by what the role actually requires · and no more (the compartmentalisation, or least-privilege, principle). In addition, an up-to-date list must be kept · which roles exist, what permissions each role has, and who currently fills it. In a medium or high database, identification and authentication duties are added (regulation 9) as well as automatic access logging (regulation 10), and when an employee ends a role · their permissions must be cancelled at once (regulation 9(c)).
Example: in a payroll bureau, a data-entry clerk can enter working hours but cannot see the bank accounts of all the employees, while the payroll manager may see the payment data. When an employee leaves · their permission is cancelled that same day and recorded in the list of valid permissions.
Documenting and handling security incidents
When something goes wrong · a breach, unauthorised use, a leak · the Regulations set out what to document, how to respond, and when reporting to the Registrar is mandatory. This is the heart of dealing with security incidents.
Regulation 11 · documenting security incidents
Unofficial English translation
(a) A database owner is responsible for documenting every case in which an event is discovered that raises a concern of harm to the integrity of the information, of its use without permission or of exceeding a permission (hereinafter – security incidents); as far as possible, that documentation shall be based on automatic logging.
(b) In the security procedure, the database owner shall also lay down provisions on dealing with information-security incidents, according to the severity of the incident and the degree of sensitivity of the information, including on the cancellation of permissions and other immediate steps required, and also on reporting to the database owner on security incidents and on the actions taken following them.
(c) In a database subject to the medium security level, the owner shall hold a discussion at least once a year on the security incidents and examine the need to update the security procedure; in a database subject to the high security level, such a discussion shall be held at least once a quarter.
(d) Where a serious security incident has occurred –
(1) the database owner shall notify the Registrar of it immediately, and shall also report to the Registrar on the steps it took following the incident;
(2) the Registrar may direct the database owner, other than a database owner of those listed in section 13(e) of the Law, after consulting the head of the National Cyber Directorate, to notify a data subject who may be harmed by the incident of the security incident.
Binding text · Hebrew original (Reshumot / Nevo)
(א) בעל מאגר מידע אחראי לתיעוד כל מקרה שבו התגלה אירוע המעלה חשש לפגיעה בשלמות המידע, לשימוש בו בלא הרשאה או לחריגה מהרשאה (להלן – אירועי אבטחה); ככל האפשר יבוסס התיעוד האמור על רישום אוטומטי.
(ב) בנוהל האבטחה יקבע בעל מאגר מידע גם הוראות לעניין התמודדות עם אירועי אבטחת מידע, לפי חומרת האירוע ומידת רגישות המידע, לרבות לעניין ביטול הרשאות וצעדים מיידיים אחרים הנדרשים וכן לעניין דיווח לבעל המאגר על אירועי אבטחה ועל פעולות שננקטו בעקבותיהם.
(ג) במאגר מידע שחלה עליו רמת האבטחה הבינונית, יקיים בעל המאגר דיון אחת לשנה לפחות באירועי האבטחה ויבחן את הצורך בעדכונו של נוהל האבטחה; במאגר מידע שחלה עליו רמת האבטחה הגבוהה, ייערך דיון כאמור אחת לרבעון לפחות.
(ד) אירע אירוע אבטחה חמור –
(1) יודיע על כך בעל המאגר לרשם באופן מיידי, וכן ידווח לרשם על הצעדים שנקט בעקבות האירוע;
(2) רשאי הרשם להורות לבעל מאגר המידע, למעט לבעל מאגר מידע מן המנויים בסעיף 13(ה) לחוק, לאחר שנועץ בראש הרשות הלאומית להגנת הסייבר, להודיע על אירוע האבטחה לנושא מידע שעלול להיפגע מן האירוע.
Explanation · not part of the RegulationsFirst of all · document every suspicion of harm to information, of unauthorised use or of exceeding a permission, preferably automatically. The security procedure should set out in advance how to respond according to the severity of the incident · including cancelling permissions and immediate steps. A medium database holds a periodic lessons-learned discussion once a year, and a high database once a quarter. And when there is a serious security incident (a term defined in regulation 1) · the Registrar must be notified immediately, and the Registrar may direct that the data subjects who may be harmed be informed as well.
Example: unauthorised entry is discovered into the payroll system of a high-level database. The owner documents the incident, cancels the permission that was used, notifies the Registrar immediately and reports on the steps taken · and if the Registrar so directs, also notifies the employees whose data was exposed.
Periodic audits · verifying that security works
Security is not a one-off event. Regulation 16 requires a check from time to time · independently · that the measures really exist and function.
Regulation 16 · periodic audits
Unofficial English translation
(a) In a database subject to the medium or high security level, the owner is responsible for ensuring that, at least once every 24 months, an internal or external audit is carried out, by a party suitably qualified to audit information-security matters who is not the security officer of the database, in order to verify its compliance with the provisions of these Regulations.
(b) In the audit report, the auditor shall report on the suitability of the security measures to the security procedure and to these Regulations, identify deficiencies and propose the measures required to remedy the situation.
(c) The database owner shall consider the audit reports transmitted to it, and examine the need to update the database definitions document or the security procedure in their light.
(d) A database owner subject to the high security level may fulfil the duty set out in this regulation as part of the conduct of a risk survey that satisfies what is stated in sub-regulation (b).
(e) An organisation that owns several databases may fulfil the duty set out in this regulation by means of a single audit covering all the databases in its possession that are at the same security level.
Binding text · Hebrew original (Reshumot / Nevo)
(א) במאגר מידע שחלה עליו רמת האבטחה הבינונית או הגבוהה, בעל המאגר אחראי לכך שתיערך, אחת ל־24 חודשים לפחות, ביקורת פנימית או חיצונית, על ידי גורם בעל הכשרה מתאימה לביקורת בנושא אבטחת מידע שאינו ממונה האבטחה של המאגר, כדי לוודא את עמידתו בהוראות תקנות אלה.
(ב) בדוח הביקורת ידווח המבקר על התאמת אמצעי האבטחה לנוהל האבטחה ולתקנות אלה, יזהה ליקויים ויציע אמצעים הדרושים לתיקון המצב.
(ג) בעל מאגר המידע ידון בדוחות הביקורת שיועברו לו, ויבחן את הצורך בעדכון מסמך הגדרות המאגר או נוהל האבטחה בעקבותיהם.
(ד) בעל מאגר מידע שחלה עליו רמת האבטחה הגבוהה, רשאי לקיים את החובה הקבועה בתקנה זו במסגרת עריכת סקר סיכונים שמתקיים בו האמור בתקנת משנה (ב).
(ה) ארגון שהוא בעל כמה מאגרי מידע, רשאי לקיים את החובה הקבועה בתקנה זו במסגרת ביקורת אחת לעניין כל מאגרי המידע שברשותו, המצויים באותה רמת אבטחה.
Explanation · not part of the RegulationsIn a medium or high database, an audit must be carried out at least once every 24 months · and not by the person responsible for security itself, to keep the review independent. The audit identifies deficiencies and proposes fixes, and the owner must consider the findings and update the database definitions document or the security procedure as needed. In a high database the duty may be met within a risk survey, and an organisation with several databases at the same level may combine the audit.
Example: a company with a medium-level customer database hires an external accountant or security consultant who is not its own security officer to carry out an audit once every two years. The report finds that old permissions were not cancelled · and the company fixes this and updates the procedure.
Two examples · how it fits together
Two cases show how the same system of levels and duties works on different databases. The examples are for illustration only · the precise classification depends on the characteristics of the database under the Schedules.
Example 1 · a small employer's staff database
Nature of the databasePayroll and staff management
Number of authorised personsUp to ten
UseRunning the business only
Security level (First Schedule item 2)Basic
What is requiredDefinitions document · physical security · permissions · incident logging
Example 2 · a service bureau with a large database
Nature of the databaseDelivering information to another as a business
ScaleOver 100,000 data subjects
Security level (Second Schedule)High
On top of the basic dutiesRisk survey and penetration tests · once every 18 months
And alsoAudit once every 24 months · immediate notice to the Registrar of a serious incident
Explanation · not part of the RegulationsThe examples are general only. Classifying a database into a security level is done under the First and Second Schedules and on its own circumstances · and in a payroll database note that salary data is defined as information of special sensitivity. In every specific case, check the binding text and consult a professional.
Holding the personal data of employees and customers?
NETO runs an employment and payments platform and manages personal data in line with the Law and the Regulations · data security, access management and respecting data-subject rights. For foreign companies hiring in Israel through our Employer of Record, NETO is the legal employer and handles privacy and data-security compliance for the employed worker on your behalf. Operating under Bareket I.T Ltd, manpower license #1565. Talk to us and we'll explain.
Test your knowledge · the Data Security Regulations
Five short questions on the main points of the Regulations. Choose an answer for each · the system will mark it immediately and show the relevant regulation.
1 How many security levels do the Regulations set?
Correct · regulation 1 sets three security levels: basic, medium and high, by the characteristics of the database.
2 When does a database fall into the high security level under the Second Schedule?
Correct · under the Second Schedule, the high level applies when the database holds information about 100,000 people or more, or the number of authorised persons exceeds 100.
3 Under regulation 8, how is the access permission for each role set?
Correct · regulation 8(a) provides that the access permission for each role shall be to the extent required for the performance of the role only.
4 What must the owner do when a serious security incident occurs?
Correct · regulation 11(d) requires notifying the Registrar immediately and reporting on the steps taken following the incident.
5 How often is a periodic audit required in a medium or high database?
Correct · regulation 16(a) provides for an internal or external audit at least once every 24 months, by a party who is not the security officer.
This quiz is for illustration and learning only and is not legal advice. In every specific case, check the text of the Regulations and consult a professional.
The Data Security Regulations · questions and answers
How many security levels do the Regulations set?
Regulation 1 sets three security levels: basic, medium and high. The level is derived from the characteristics of the database under the First and Second Schedules. Basic · any database not in the Schedules and not managed by an individual; medium · databases in the First Schedule (delivering information to another, a public body, sensitive information and more); high · databases in the Second Schedule. The higher the level, the greater the security duties.
When does a database fall into the high security level?
Under the Second Schedule, the high security level applies to a database of the types in item 1(1) or 1(3) of the First Schedule that contains information about 100,000 people or more, or in which the number of authorised persons exceeds 100. Such a database also requires a risk survey and penetration tests at least once every eighteen months, and a periodic audit once every 24 months.
What is the database definitions document and what must it include?
Regulation 2 requires every owner to define in a document: a description of the collection and use, the purposes of use, the types of information (with regard to sensitive information), particulars of transfers abroad, processing through a holder, the main risks and how they are dealt with, and the names of the database manager, the holder and the information-security officer. The document is updated on a significant change and reviewed once a year · and you also check that no unnecessary information is kept.
How are access permissions to a database set?
Regulation 8 provides that access permissions are set in accordance with job definitions, and that the access permission for each role shall be to the extent required for the performance of the role only. A list of valid permissions must also be kept · roles, their permissions and who fills them. In a medium or high database, identification and authentication duties are added (regulation 9) and access logging (regulation 10), with permissions cancelled immediately on the end of a role.
What must be done when a serious security incident occurs?
Regulation 11 requires documenting every event that raises a concern of harm to the integrity of the information, of use without permission or of exceeding a permission. On a serious security incident, the Registrar must be notified immediately and the steps taken reported. The Registrar may, after consulting the head of the National Cyber Directorate, direct that a data subject who may be harmed by the incident be informed as well.
Where is the binding text of the Regulations found?
The binding text is the one published in the Official Gazette (Reshumot). An accessible, up-to-date version appears on Nevo and on the Privacy Protection Authority site. This page reproduces the verbatim Hebrew next to an unofficial translation and an explanation · for any legal use, rely on the official text and consult a lawyer.
In summary
The Protection of Privacy (Data Security) Regulations, 5777-2017, are the practical side of securing databases in Israel · three security levels, a database definitions document, access management, incident handling and audits. For each topic on this page we gave the verbatim Hebrew of the regulation next to an unofficial translation and an explanation. NETO manages personal data in line with the Law and the Regulations, under manpower license #1565.
- Security levels · basic, medium and high, by the characteristics of the database (regulation 1).
- Database definitions document · mapping the information, purposes, risks and responsible people (regulation 2).
- Access control and incidents · permission by role (regulation 8), documentation and notice to the Registrar (regulation 11).
- Periodic audit · once every 24 months for a medium or high database (regulation 16).
Further reading: Privacy Protection Law · the full text · NETO privacy policy · Wage Protection Law. Official text: the Regulations on Nevo.
Last updated: 27 July 2026 · the regulation text was cross-checked against the official Hebrew version on NevoRelated guides and laws
Wage Protection Law
How wages must be paid and protected in Israel · in plain language for employers and workers.
Read more
Israeli labor law at a glance
The main labor laws, regulations and orders · a convenient roundup for employers and workers.
Read more
