Banking & finance
The examiner will ask who approved it.
The answer has to be a record, not a memory.
In a bank, patching rarely stalls on anything technical. It stalls on thirty system owners, on a freeze that starts two weeks before quarter-end, and on a payments system nobody will take down without something in writing. Regulaxy runs exactly that part, and leaves the evidence behind it.
The banking constraint
- Supervision
- Directive 364 requires a documented patching process, a treatment time proportionate to the asset's criticality, and an audit trail for every change.
- Distributed ownership
- Every system has a different owner, a different calendar and a different tolerance for downtime. Nobody can decide for all of them.
- Freezes
- Quarter-end, year-end, holidays and peak days. A meaningful share of the calendar is closed before you start.
- Dependencies
- Payments leans on a database that leans on an identity service. None of the three teams can see that chain at the moment they book a window.
364 replaced 357, 361 and 363 in November 2024.
What breaks today
The process exists. It just isn't written down anywhere.
Every bank can describe its patching procedure. The gap is between the procedure and what can be shown to have happened.
The patch is ready, the window isn't
Months pass between a vendor publishing a fix and it being installed — not for technical reasons, for coordination ones. A window slipped twice usually slips a third time.
The approval was a phone call
The owner agreed verbally, or in mail nobody kept. When the audit comes there is nothing to reconstruct who approved what, when, and on what basis.
Two systems, one night
Two teams booked the same hour on systems that depend on each other. It surfaces at 3am, on the phone.
Evidence assembled afterwards
Before an audit somebody spends a week building a table out of screenshots and mail. The table is accurate. The process it describes did not happen that way.
What changes
The same process, except it writes itself down as it runs.
Nobody is being asked to work differently. The record happens during the work instead of after it.
The window is booked once
Five steps: update type, hosts, owner and contacts, date and time, review. Out the other side come two calendar invites and a reminder.
The approval is a database row
Who approved, when, over which hosts, against which text. Not a mail sitting in one person's folder.
Collisions are blocked at booking time
The dependency map is read from the infrastructure itself. A window that collides with a linked system is flagged while you are booking it, not during it.
The export is the evidence
A styled Excel file or CSV with every window, its owner, its approval and the checklist that was signed. That is what you hand the examiner.
Directive 364
Where this meets the directive.
The full table — clause against producible evidence — lives on its own page.
The full table — clause against producible evidence — lives on its own page.
See the full Directive 364 mappingThe capabilities this touches
The pages that explain how each one actually works.
Questions
Questions we actually get
Let us run it against your own inventory.
A 40-minute session, on demo data or on an inventory export of yours. Nothing to install.
- Or start from the Directive 364 mapping and see which evidence is missing today.