Regulatory evidence
Directive 364, clause against evidence.
Without claiming we make you compliant with it.
Proper Conduct of Banking Business Directive 364 — management of IT risk, information security and cyber defence — took effect in November 2024 and consolidated Directives 357, 361 and 363. This page does one thing: it puts the producible evidence next to each relevant clause, and states plainly where the boundary is.
357 → 364
357 is no longer current
Directive 357 is still searched for more than 364 is. It was consolidated into 364 along with 361 and 363. If an internal document of yours still cites 357, that citation is out of date — the patch-management content now sits at §61.4.
§10
Who the directive applies to
§10 sets the scope: banking corporations as defined in the Banking (Licensing) Law, corporations under §§11(a)(3a), 11(a)(3b) and 11(b), and payment-service providers of systemic importance under §36i.
The mapping
What is asked for, and what can be shown.
The first column is written in the directive's own framing. The second is what the product actually emits — not a promise, an output.
- §61.4What the directive asks for
A process ensuring that functional and non-functional patches are applied within a timeframe commensurate with the criticality of the patch and the sensitivity of the information asset, and tested in a separate environment before production.
- What Regulaxy produces
Patch cadence derives from each host's exposure level and is computed onto every inventory row alongside its next due date. The priority score is shown with every term that produced it and how much each contributed, so you can explain why one system went before another.
Patch status report by system
- §97What the directive asks for
Defined procedures for assessing, approving and promoting to production emergency changes that cannot follow the regular change process, including naming the authorised approver.
- What Regulaxy produces
An emergency change is recorded like any other window, with who approved it and when, and the checklist completed at execution time. The distinction between a planned and an emergency change stays visible on the record instead of disappearing afterwards.
Timestamped approval record
- §98What the directive asks for
Retention of an audit trail of the activities performed during change implementation, to support investigation and problem resolution during and after the change.
- What Regulaxy produces
The audit log is separate from the event itself: it survives an event being permanently deleted, because it is the record that the deletion happened. The checklist answered during execution is stored with its own schema, so a later edit to the form cannot change an old answer.
Audit log + signed checklist
- §114.7What the directive asks for
Vulnerability-management controls ensuring rapid, risk-based treatment of discovered vulnerabilities.
- What Regulaxy produces
A vulnerability register whose grain is the patch rather than the CVE: one patch carries every vulnerability it fixes and every host it touches, and a window is booked from it. Host attribution is marked explicitly as a scan result or as an estimate, never shown as the same thing.
Vulnerability register by patch
- §114.8What the directive asks for
Controls for assessing patches and updates for discovered vulnerabilities and applying them within a reasonable time.
- What Regulaxy produces
Per patch: when it entered the register, which hosts it touches, which window it was booked into and what happened there. The interval between those two dates is the measure, and it is read out of the system rather than assembled by hand.
Time-to-remediate export
- §61.3What the directive asks for
Identification of end-of-life and end-of-support assets, and assessment of the resulting risk.
- What Regulaxy produces
Operating system and version appear on the inventory row and can be filtered and exported on. The product does not carry a vendor end-of-support database — that list comes from you.
Inventory export by version
What this page is not saying
The Banking Supervision Department examines you, not your tooling. That distinction is not only legal — it changes what it is reasonable to expect from the product.
- We do not claim Regulaxy is compliant with Directive 364, or that it makes you compliant with it. That claim has no regulatory meaning.
- We hold no Bank of Israel approval, certification or opinion, and the Banking Supervision Department does not approve products.
- The evidence the product emits is evidence of a process you operate. If the process is not run, better documentation will not make it look better.
- This mapping is our reading of the directive's text. It is not a substitute for your own compliance adviser's opinion.
That wording is deliberate: a vendor promising compliance is a vendor your compliance team disqualifies in the first meeting.
Which evidence is missing today?
We can walk these six clauses against what you hold right now and mark the gaps. That is an hour, not a product demo.
- All Directive 364 copy on this site is pending legal review before publication.