DPO DPO Israel
Open as Markdown
How-To

Information Security Procedure Template

The written information security procedure is the document the Israeli Privacy Authority asks for first in any audit. The 2017 Information Security Regulations require it for every database, at every security level — and Amendment 13 raises the price of getting it wrong. Here is what a serious procedure looks like, what changes by security level, and how it integrates with the database definition document.

Why a written security procedure — 2017 regulations requirement

The 2017 Information Security Regulations are not a recommendation — they are binding secondary legislation. Article 4 explicitly requires a written, signed, and current information security procedure for every database, at every security level (basic, medium, high). The procedure is the single document the Israeli Privacy Authority asks for first in an audit. Without it, you have an automatic finding — regardless of what controls actually exist in practice. A good procedure is not a wall poster; it is the working document that translates law into day-to-day operations: who is allowed to do what, with which data, under what conditions, and what to do when something goes wrong.

Three security levels and their procedure implications

The regulations divide databases into three levels. Basic level — a small database, non-sensitive data, no third-party transfers. Procedure is short (15-20 pages) and focuses on appointments, permissions, backups, and incidents. Medium level — sensitive data (health, financial, biometric) or 100,000+ data subjects, or vendor transfers. Procedure expands to 25-30 pages with documented risk survey, periodic penetration testing, and stricter permission controls. High level — sensitive data at scale or critical national infrastructure. Procedure is 35-40 pages and adds detailed monitoring, logging, physical access controls, and quarterly review.

Mandatory clauses (appointments, permissions, backups, incidents, deletion)

Every procedure — at every level — must contain at minimum: (1) Appointments — database owner, Information Security Manager, and if relevant DPO; (2) Authorized users and permission policy — who is allowed access, on what basis, with what authentication method; (3) Backups — frequency, location, recovery testing; (4) Incident handling — who is notified, within what timeframe, who decides on Authority/data-subject notification (see incident response); (5) Retention and deletion — how long each data type is retained, and what the secure deletion procedure is.

Additional clauses at medium security level

At medium level the procedure must add: annual risk survey documented in writing with action conclusions; vendor management — every vendor with database access requires a written agreement, security questionnaire, and Article 15 controller-processor terms (see vendor privacy); encryption — encryption requirement at rest and in transit, including key management; employee training — annual training, documented, with checking comprehension; access review — semi-annual review of who has access to which database and is the permission still justified.

Additional clauses at high security level (logs, monitoring, physical access)

High security level adds three significant layers. Logs and monitoring — detailed logging of every access to sensitive data, log retention at least 24 months, anomaly monitoring (failed login attempts, unusual access from a new country, bulk export). Physical access — production environment in a locked server room, access by ID card with documentation, security camera at server room entrance. Penetration testing — annual external penetration testing, with documentation of findings and treatment. Quarterly review — quarterly procedure review, not just annual. Many organizations underestimate the cost of high level — and discover it only when the Authority shows up.

Relationship to database definition document

The security procedure and the database definition document are two sides of one coin. The definition document describes what is in the database — fields, purposes, data subjects, vendors, retention period. The procedure describes how we protect what is in the database. The two documents must be perfectly consistent — every database vendor in the definition document must appear in the vendor section of the procedure; every retention period in the definition document must match the deletion section of the procedure. In an audit, the Authority compares the two documents side by side. Any inconsistency = a finding.

Employee training on the procedure

A procedure no one read is a procedure that does not exist. The regulations require annual employee training in information security and privacy — and require documentation of who participated, when, with what comprehension test. A standard 60-minute training covers: what is personal information, the legal duty under Amendment 13, key clauses of the organizational procedure, how to identify a phishing attempt, what to do when a security incident is suspected, how to handle a data subject access request. Training tailored by role (technical employees vs. administrative employees) is significantly more effective than generic training, and shows the Authority a serious approach.

Periodic maintenance and updates

A security procedure is not a one-time document. The 2017 regulations require annual update at minimum, and immediate update upon significant change — adding a new system, change of central vendor, organizational change, addition of new database. Practically, we recommend a fixed quarterly review: 30 minutes with the Information Security Manager and DPO, going through the appointment list, vendor list, and incident log of the past quarter. Approximately every three years it is worth bringing in an external consultant to refresh the procedure from scratch — laws and threats change faster than organizations update.

How we build custom procedures

We do not sell a generic Word template. Every procedure we build starts with a one-hour conversation with the database owner and Information Security Manager, continues with mapping the actual databases and existing controls, and ends with a procedure precisely tailored to the actual security level and processing types. As part of DPO as a Service and GRC privacy, the procedure is delivered together with the database definition document and employee training kit. The procedure is signed by the database owner and Information Security Manager, and the annual update is included in the retainer.

Frequent questions about the security procedure

Is there a generic procedure template I can download from the internet?
There are dozens of templates online, and most of them are problematic. Some are translated from US standards (HIPAA, SOC 2) and do not match Israeli regulations; some are 5-year-old templates not updated to Amendment 13 which became effective in 2025; some are generic templates not adapted to the actual security level of the organization. A wrong template is worse than no template — it creates a false sense of security and supplies the Authority with a convenient document to find inconsistencies in. A custom procedure costs 8,000-25,000 ILS by complexity. Significantly cheaper than the sanction for non-compliance.

How long does it take to build a procedure from scratch?
For a basic-level database — 2-3 weeks. Includes initial conversation, database and vendor mapping, draft writing, review with Information Security Manager and database owner, finalization, and signature. For a medium-level database — 3-5 weeks. For high-level — 6-8 weeks, including detailed risk survey and consultation with the IT team. The most common mistake is "we will do it in a week" — and ending up with a procedure that does not really reflect the organization. Worth investing the time properly once.

Who signs the procedure?
Mandatory: the database owner (CEO or whoever was formally appointed) and the Information Security Manager. Recommended: the DPO too, if appointed, as proof that they were involved in writing. In medium and high levels — also a CISO if there is one separate from the Information Security Manager. The signatures must appear on the cover page with date, and a new signature is required upon every annual update.

Does the procedure need to be in Hebrew or English?
The procedure must be readable by anyone who needs to follow it. In an Israeli organization with Hebrew-speaking employees — Hebrew is mandatory, regardless of how multinational the organization is. If you have an English-speaking technical team — best practice is a bilingual document with key sections in both languages, or two parallel versions. The Authority is fine with English if the organization is genuinely international, but expects the version employees actually read to be in the language they understand.

What happens if I have a procedure but do not actually follow it?
Worse than no procedure. In an Authority audit they not only read the document — they cross-check with reality: they ask employees questions, look at access logs, request training records. A procedure that says "annual penetration testing" but is not actually performed = direct evidence of a gross breach. Better an honest 15-page procedure that is actually executed than an elegant 40-page procedure that is a shelf decoration.

Do we need to share the procedure with external vendors?
Not the full procedure — it contains internal information. But every vendor with database access must receive the vendor-relevant parts: data handling requirements, incident notification requirements, audit rights. This usually arrives as a security appendix to a controller-processor agreement under Article 15 of Amendment 13. The vendor must sign on receipt and undertake to comply. See our vendor privacy service.

Is the procedure included in DPO as a Service?
Yes. In every DPO as a Service retainer we deliver an updated security procedure aligned with the database definition document, annual update, and employee training. For a one-off pre-audit project the procedure is delivered as part of the gap analysis deliverable. Worth comparing pricing — for most organizations, annual retainer is cheaper than two ad-hoc projects per year.

Are there sectors that need special procedure clauses?
Yes. Healthcare requires additional clauses on Patient Rights Law and consent for sharing with HMOs / specialists. Finance requires alignment with Bank of Israel Directive 357 and Capital Markets Authority rules. Local government and authorities requires alignment with Government CIO and Cyber Directorate guidelines. Education requires special clauses on processing minors’ data. In every sector vertical we operate, we keep an industry-specific procedure template that is updated quarterly.

Need a security procedure that survives an audit?

30-minute call, quote within 48 hours, signed procedure within 3-6 weeks.

DPO as a Service details