Amendment 13 to Israel's Privacy Protection Law: a checklist for donor and volunteer databases

Note: general recommendations only, not professional advice, and not legal advice. This playbook helps you prepare for a conversation with a lawyer, it doesn't replace it. Before any decision, consult a lawyer. The full text is at the end.

Who this is for

For a nonprofit CEO, an operations manager or a board member who is responsible for lists of donors, volunteers, participants or newsletter subscribers. No legal or technical background needed. You need a Google Sheets or Excel spreadsheet, an hour or two a week, and access to the people who manage the lists.

The problem in three lines

Every nonprofit holds data about people, and it's scattered: a donor sheet, a volunteer sign-up form, WhatsApp groups, an email inbox, receipt software. Nobody knows exactly what was collected, who accesses it, and what you told people when you collected it. And when the law changes, it's hard to know what applies to you, and a conversation with a lawyer without preparation turns into a long and expensive one.

What is known, and what you check with a lawyer

Only general facts that appear in professional publications about the amendment are written here. Everything else is asked later as a question for the lawyer.

• Amendment 13 to the Privacy Protection Law, 5741-1981, came into force on August 14, 2025.
• The amendment narrowed the duty to register databases, and added new duties.
• The amendment broadened key definitions in the law, such as "personal information".
• The amendment gave the Privacy Protection Authority new enforcement powers, including financial sanctions (administrative fines).
• The amendment requires certain bodies to appoint a privacy protection officer. Whether your nonprofit must do so is a question for the lawyer.
• Separately from the amendment, the Privacy Protection (Data Security) Regulations, 5777-2017, set security duties for databases.

The updated text, guidance and forms are published on the Privacy Protection Authority's site at gov.il. Read there before the meeting with the lawyer, because guidance gets updated.

The method in 7 steps

Step 1: A database map

What to do: Write down every place where there is data about people. Not just the official "database".

How: Open a sheet called "Database map", one row per place. Go through it with every team member and ask: "Where do you have people's names, phone numbers or emails?". Places worth checking:

• The donor sheet or system, and the receipt software.
• Sign-up forms for volunteers and activities, and the sheet the form fills.
• The newsletter mailing list.
• WhatsApp groups of volunteers and participants.
• Email inboxes with attachments (CVs, certificates, ID scans).
• Shared cloud folders, and files on personal computers.
• Paper files.

Columns in the sheet: database name, where it is, about whom (donors, volunteers, participants, minors), roughly how many people, who is responsible, since when.

Common mistake: Mapping only the donor system. Usually the more sensitive data is in an old sign-up form or in the inbox of a volunteer who left two years ago.

Step 2: What is collected, and why

What to do: For every database, write down the fields being collected, and for every field the purpose it's collected for.

How:

• Copy the header row of every sheet or form. Not the data itself.
• Next to every field write why it's needed. "Phone: for reminders before a shift". "ID number: for a tax receipt".
• A field with no clear purpose gets marked "check whether needed". Don't collect data "just in case".
• Mark fields that look sensitive: health, financial situation, criminal record, religion, data about minors. What counts under the law as "information of special sensitivity" is a question for the lawyer.

AI can help here (prompt 2), but only with the header row. Don't paste the lists themselves into it.

Common mistake: Leaving fields in a form that were copied from another organization's form, like "date of birth" or "marital status", when nobody uses them.

Step 3: Who accesses the data

What to do: For every database, write down who can view, who can edit, and how people log in.

How:

• Check the sharing permissions on every file and folder. Mark "anyone with the link" in red.
• Write down people who stopped working or volunteering and still have access, and remove them.
• Check whether two-factor authentication is on for accounts that hold databases.
• Check whether several people share one password.
• Decide who in the nonprofit is responsible for permissions, and write down their name.

Common mistake: Thinking a WhatsApp group isn't a database. Everyone in the group sees everyone else's number.

Step 4: What you tell people when you collect their data

What to do: Collect all the wording people see when they leave their details: donation form, volunteer form, newsletter sign-up, privacy policy on the website.

How:

• Save a screenshot of every form as it is today.
• For every form check: does it say why the data is collected, what will be done with it, whether giving it is mandatory, and who it will be passed to.
• Check whether there's separate consent for marketing emails, and whether there's a simple way to remove yourself from the list.
• AI can write a draft in plain language (prompt 4). The lawyer approves the final wording.

Common mistake: Copying a privacy policy from another organization's website. It describes databases and uses you don't have, and doesn't describe the ones you do.

Step 5: Vendors and outside systems

What to do: Write down every outside service that holds data about your people.

How: One row per vendor: mailing system, payment and donation system, receipt software, donor management system, cloud storage, AI tools the team uses, the accountant, the vendor who manages your website.

For every vendor: what data it holds, whether there's a written agreement, who in the nonprofit manages the relationship, and how you get the data out if you leave.

Common mistake: Forgetting a vendor that was opened as a free trial and forgotten. The data is still there.

Step 6: Basic security and an incident procedure

What to do: Close the simple gaps, and write a short procedure for a leak.

How: Actions you can take this week:

• Two-factor authentication on every account that holds a database.
• Cancel "anyone with the link" sharing.
• Remove access for people who left.
• Delete old files that aren't needed, after checking with the lawyer and the accountant how long what must be kept.
• Back up the important databases.

A one-page incident procedure: who to report to inside the nonprofit, who decides, how to stop the leak, and how to document what happened and when. Whether and when you must report to the Privacy Protection Authority is a question for the lawyer, and it's worth asking before anything happens.

Common mistake: Writing the procedure after the incident. During an incident there's no time to find out who decides.

Step 7: A documentation file and a meeting with the lawyer

What to do: Bring everything you collected into one folder, and take it to the lawyer.

How: In the folder:

1. The database map (step 1).
2. The fields and purposes table (step 2).
3. The permissions table (step 3).
4. The screenshots of the forms and the privacy policy (step 4).
5. The vendor list (step 5).
6. The incident procedure (step 6).
7. The list of questions (in the next section).

After the meeting, write down what was decided, who is responsible and by when, and update the file. Set a date for a repeat check, for example once a year, and every time you add a database or a vendor.

Common mistake: Treating this as a one-off project. New databases open all the time, with every new form for an event.

Questions for the lawyer

• Given its size and type of activity, must our nonprofit appoint a privacy protection officer?
• Does any of our databases still require registration, or any notice to the Privacy Protection Authority, after the amendment?
• Which of the fields we collect count under the law as information of special sensitivity, and what does that require?
• What must appear in the forms where we collect data, and what is missing from our wording today?
• Do we need separate consent for mailings to donors and volunteers, and in what wording?
• Which duties from the Data Security Regulations apply to each of our databases?
• What should be in the agreements with vendors who hold data for us?
• What may and may not go into AI tools, and what clause should we add to the team's working rules?
• If we hold data about minors, what does that change?
• How long may and must we keep data about former donors and former volunteers?
• When is it mandatory to report a security incident to the Authority, and to whom else?
• What is our exposure to sanctions, and what is the first thing worth fixing?

Ready-made prompts

One rule for all the prompts: don't paste names, phone numbers, emails, ID numbers or any detail of a real person. Only column headers, form wording and general descriptions.

I run a nonprofit in the field of [field], with [number] staff and about [number] volunteers. We work with [tools: Google Sheets, Gmail, WhatsApp, a mailing system...].
Write me a short list of questions to ask every team member, to find every place where there is data about people: files, forms, inboxes, groups, systems, paper.
Simple questions, no legal terms.

These are the column headers in the sheet [database name], without data: [paste headers].
The database is used for: [short description].
For every column: what its likely purpose is, whether it seems necessary for that purpose, and whether it might be sensitive data (health, financial situation, criminal record, religion, minors).
Don't determine what the law requires. At the end, list questions for a lawyer about the fields you marked.

I want to check who accesses our databases. The databases: [list of database names and where they are].
Build me an empty table to fill in, with the right columns, and short instructions on how to check sharing permissions in [Google Drive / OneDrive / your tool].

Write a plain-language draft of a notice to appear on a nonprofit's [volunteer sign-up / donation / newsletter] form.
Data collected: [list of fields]. What is done with it: [uses]. Who it is passed to: [vendors / nobody]. How to contact us: [address].
Up to 120 words. At the end add: "Draft. For a lawyer's review before publishing". Don't write that the wording meets the requirements of the law.

Write a one-page procedure for a small nonprofit, for a case where data about donors or volunteers leaked or was sent by mistake.
Include: who to report to inside the nonprofit, who decides, first steps to stop the leak, documentation (what, when, who), and a step "consult a lawyer about reporting duties".
Don't set legal reporting duties or deadlines. Leave them as [check with a lawyer].

Here is our list of questions for the lawyer about privacy protection: [paste]. And here is a short version of the database map, without personal details: [paste].
Order the questions by importance, merge repeated questions, and add our context to each question in one sentence. Don't answer the questions.

One-page checklist

Mapping

• Database map, including WhatsApp, email, cloud and paper
• For every database: about whom, how many, who is responsible
• Fields table with a purpose for every field
• Sensitive fields marked
• Fields with no purpose marked for review

Access and security

• Permissions checked, no "anyone with the link" sharing
• People who left removed
• Two-factor authentication on every account with a database
• Backups of the important databases
• One-page incident procedure

Forms and vendors

• Screenshot of every form and the privacy policy
• Vendor list, with or without an agreement
• Working rules for AI tools

The lawyer

• Complete documentation file
• Ordered list of questions
• Summary of decisions, owners and dates
• A repeat check date in the calendar

How you know it's working

• Coverage: every team member was asked, and every database that came up is on the map.
• Open sharing: the number of files shared with "anyone with the link". The goal is zero.
• Unneeded access: the number of people who left and still have access. The goal here is zero too.
• Unneeded fields: how many fields were removed from forms because they weren't needed.
• Decisions: how many of the questions for the lawyer got an answer, a decision and an owner.
• Updating: the file was last updated less than a year ago, and every time a database or vendor was added.

Disclaimer

This content is general recommendations only, not professional, legal, accounting or tax advice. It doesn't interpret the law and doesn't determine what applies to your organization. The facts about Amendment 13 are presented briefly and in general terms, and the law, the regulations and the guidance may change. Every organization is different, and you are responsible for checking that the content fits your situation. Before any decision on privacy protection, database registration, appointing an officer, form wording, vendor agreements or incident reporting, consult a lawyer. Read the updated text of the law and the guidance on the Privacy Protection Authority's site.