Reading Directive 364 §61.4 as an operations requirement
What the patch-management clause of Bank of Israel Directive 364 actually requires, which operational decisions it forces, and what has to be written down to have anything to show.
- By
- Gidi Rabi · Regulaxy engineer
- Updated
- 4 min read
- Directive 364
- regulation
- patch management
Bank of Israel Proper Conduct of Banking Business Directive 364 — Management of Information Technology Risks, Information Security and Cyber Defence is the document an auditor points at when they ask about security updates. Clause 61.4, "patch management", is two paragraphs. They are worth reading slowly, because nearly every phrase in them is an operational decision somebody has to make.
What the clause says
In substance it requires two things:
- A process ensuring the application of patches — functional and non-functional — within a timeframe commensurate with the criticality and sensitivity of the patch and of the information asset.
- Testing in a separate environment before deployment to production, to verify the patch suits the existing information assets and does not cause failures in the IT array.
Emergency patches that cannot follow the normal process are routed to clause 97.
Four decisions hidden in the first paragraph
"A process" — not a task list
The word is not decoration. A process is something you can point at: it has a defined input, stages, an owner per stage, and you can reconstruct what happened in it. A manually maintained spreadsheet is not a process — it is an artefact of one that exists in a single person's head.
"Within a timeframe commensurate with criticality" — you set the numbers
The directive names no number of days. That is not a loophole; it is a harder requirement. You have to define the targets and justify them.
In practice that means a matrix. Patch severity on one axis, asset criticality on the other, a number of days in each cell. Then you have to measure against it, because a target nobody measures against is a statement of intent.
"Functional and non-functional" — not only security
The clause explicitly names bug fixes, not only vulnerability fixes. An organisation managing only its security updates is managing half of what is being asked, and this usually surfaces when someone asks why the version running in production is no longer supported. (That is clause 61.3, EOL/EOS identification, but it gets discovered from here.)
"In a separate environment" — and who confirms it happened
The second requirement is easy to state and irritating to evidence, because it means the fact "tested in a test environment" has to be recorded somewhere beside the window in which the update reached production. If it is not recorded there, there is no way to prove it two months later.
The simple answer is an execution checklist with exactly that line on it, closed by whoever did the work rather than by whoever writes the summary.
What has to exist at the end
This is the list to check yourself against. Per maintenance window:
| What | Why it is there |
|---|---|
| The patch and the vulnerabilities it closes | Ties the action to its reason |
| The affected assets | Defines the scope of the change |
| The ranking and its components | Justifies the timeframe chosen |
| The owner's approval, timestamped | Evidence that someone authorised agreed |
| Execution: who, when, what was done | Clause 98 — the audit trail |
| Outcome, including failure | An unrecorded failure is the finding |
Five of those six rows create themselves if the process runs in one tool. When it runs in a spreadsheet and email, each of them is manual work somebody has to remember.
The two adjacent clauses
§97 — emergency changes. Requires defined procedures for assessing, approving and promoting to production changes that cannot follow the regular change-management process, and naming the authorised approver. In operational terms: a fast route that is still a route, not "we called the manager and he said fine".
§98 — audit trail. 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: the activities performed, not the decisions taken. A log that records approvals only does not answer it.
Why this says 364 and not 357
Because 357 has been superseded. Directive 364 consolidates and replaces 357, 361 and 363, and 364 is the correct citation today. The full guide is here: Directive 364 readiness.