Directive 364 readiness — a guide for infrastructure teams

Bank of Israel Proper Conduct of Banking Business Directive 364 — Management of Information Technology Risks, Information Security and Cyber Defence is the document people point at when they talk about security patching in a banking corporation. It consolidates and replaces Directives 357, 361 and 363.

This does not replace reading the directive, and it is not legal advice. It does one thing: it takes the three clauses that bear directly on infrastructure work and turns each into an operational question — what has to exist, and what has to be written down.

The relevant clauses at a glance

Clause	Subject	What it means in practice
61.3	EOL/EOS identification	Know what is no longer supported, and assess the risk
61.4	Patch management	A process applying patches within a timeframe matched to criticality, after testing in a separate environment
97	Emergency changes	A defined fast route, with a named authorised approver
98	Audit trail	A record of the activities performed during the change
114.2	Configuration management	Configuration that minimises vulnerabilities
114.7	Vulnerability management	Rapid, risk-based treatment
114.8	Patch-management control	Assessing updates for discovered vulnerabilities and applying them in reasonable time

Scope is set in clause 10: banking corporations as defined in the Banking (Licensing) Law 5741-1981, corporations under §11(a)(3a)/(3b) and §11(b), and payment-service providers of systemic importance under §36i.

[VERIFY] — before relying on the scope or on clause numbering in a binding document, check against the current text published by the Bank of Israel.

Clause 61.4 — patch management

It requires two things. First, a process ensuring the application of functional and non-functional patches within a timeframe commensurate with the criticality and sensitivity of the patch and of the information asset. Second, testing in a separate environment before deployment to production, to verify the patch suits the existing information assets and does not cause failures.

What follows operationally

"A process", not a task list. A process is something you can point at: defined input, stages, an owner per stage, and the ability to reconstruct what happened. A manually maintained spreadsheet is an artefact of a process that exists in one person's head.

"Within a timeframe commensurate with" — the directive names no number of days, so you must define the targets and justify them. A matrix of severity against criticality, written and approved. An unmeasured target reads in an audit as a statement of intent.

"of the patch and of the information asset" — two variables. A ranking resting on CVSS alone measures only the first of them, and so does not answer the clause as written.

"functional and non-functional" — not only security. An organisation managing only vulnerability fixes is managing half the requirement.

"in a separate environment" — easy to state, hard to evidence. The fact that the update was tested has to be recorded beside the window in which it reached production, or there is no way to show it afterwards. The simple fix is a line item on the execution checklist.

The evidence clause 61.4 expects to see

Evidence	Where it is created
Policy document carrying the time targets	Approved, dated, in force
Criticality mapping for assets	The BIA output
The ranking given to each patch, and its components	At planning time
Record of testing in a separate environment	A checklist item
Measurement against the targets	A periodic report

Clause 97 — emergency changes

It requires defined procedures for assessing, approving and promoting to production changes that cannot follow the regular change-management process, and requires naming the authorised approver.

Three questions the procedure must answer

1. What counts as an emergency

   A definition you can decide against in two minutes in the middle of the night. "A vulnerability under active exploitation on an exposed asset" is a definition. "Urgent cases" is not.

2. Who approves, by name

   A name and a role, and a deputy. The clause explicitly asks who is authorised.

3. What is recorded, and when

   What gets written as it happens, and within what period the full record is completed. "We will write it up later" with no stated period is what turns an emergency route into a bypass.

Clause 98 — audit trail

It requires retention of an audit trail of the activities performed during change implementation, to support investigation and problem resolution during or after the change.

Note the wording. It names the activities performed, not the decisions taken. A log that records approvals only does not answer the clause.

The practical test

The right question is not "do we have documentation" but "does the documentation create itself". Anything that depends on a person remembering to record it will not exist on the night it is most needed — and that is exactly the night the question gets asked about.

What the trail needs, per window:

• Who approved, when, and by what means.
• What was actually done: start time, end time, who did it.
• What failed, and what was done about it.
• Who was notified, and when.

Five questions worth preparing for

A self-check list, not a quotation from any auditor:

1. "Show me the policy, and the date it was approved." A policy with no in-force approval date is a draft.
2. "Take a critical vulnerability from six months ago and show me the chain through to the fix." This is the question that separates a process from documentation. If it takes three systems to answer, the answer is already known.
3. "Who approved this window?" On a window they pick, not one you do.
4. "What happens when an update fails?" A good answer includes an example that actually happened.
5. "How do you know the update was tested before production?" The clause requires it explicitly, and it is the easiest evidence to forget to produce.

What must never be claimed

Worth passing to whoever writes proposals and tender responses.

Permitted: "designed around the requirements of §61.4" · "produces the audit trail contemplated by §98" · "supports your evidence" · "maps to the clauses".

Not permitted: "compliant with Directive 364" · "certified" · "guarantees compliance" · "Bank of Israel approved".

This is not excessive caution. No vendor makes a banking corporation compliant, the Banking Supervision Department does not approve products, and any phrasing that sounds like certification will be caught within a minute by the buyer's own compliance team. That loses the deal for the worst possible reason.

Where to start from nothing

In order:

1. A policy document with time targets. One page is enough. Without it there is nothing to measure against.
2. An ownership map. Who approves what. Without it there are no approvals, and therefore no evidence.
3. An execution checklist. Six items. It produces most of the audit trail at the lowest cost of anything here.
4. Measurement. Median time from detection to fix, by severity. Quarterly.

The full playbook for those steps is here: A patch-window coordination playbook.