Nine programmes delivered at banking institutions
Case studies
A selection of nine programmes delivered at banking institutions — there are more, but these sum up the kind of work well. I tell them with the same structure — the challenge, the approach and the outcome — because it is the most honest way to show how I work: what matters is almost never the technology chosen, but how it reaches production without breaking anything.
All of them began with a per-service analysis signed off by the stakeholders before anything moved. Clients go unnamed for confidentiality. All are Spanish financial institutions, and in all of them I ran the programme or the project from start to finish.
300 critical servers migrated without stopping the business
In a regulated sector, a project is not judged by the technology it uses but by what happens when something goes wrong. This one sums up how I work.
01 · The challenge
A banking platform running out of support
A Spanish financial institution ran its platform on Windows Server 2008. Extended support had an expiry date and, with it, any chance of defending the infrastructure in an audit: a system that stops receiving patches is not a theoretical risk, it is a finding. There were more than 300 assets, each with its own applications, dependencies and business owner. And several critical services with no high availability: a single server standing between the service and an outage.
02 · The approach
Inventory, negotiated windows and a tested rollback
I ran the full programme for two years. First, classifying the 300 assets by criticality and dependencies, because the migration order is half the project. Then coordinating three fronts at once: the technical teams, the business owners of each application and, where the software did not support the new version, the vendor itself. Every migration window was negotiated with the business, and none touched production without a tested rollback plan. Each migration was also used to give high availability to the services that lacked it: if a server has to be moved, it gets moved once and moved properly.
03 · The outcome
Zero major incidents, delivered on time
More than 300 assets migrated to Windows Server 2016 and 2019 within the two years committed. Zero major incidents and no loss of service to the business. The institution left extended support before the deadline, which was the underlying regulatory objective. And the services that entered the project as a single point of failure came out of it in high availability.
A container platform from the idea to production
A project of the opposite kind: there was nothing to migrate, there was something to build that the organisation did not have.
01 · The challenge
Containers in a bank, starting from nothing
The organisation had no container platform and nobody with experience of one. There was nothing to migrate: the job was to justify the investment, choose the technology, buy it, train the team, build it with the redundancy a banking environment demands and put it into production. And to do it without asking IT governance or security to accept anything they could not audit.
02 · The approach
A four-year plan, certified training and two data centres
I ran the project from the initial idea. It started with the cost plan: a four-year roadmap covering rollout and growth, so the platform would be approved as an investment rather than an experiment. We chose Red Hat OpenShift and bought the hardware to host it across several data centres, with redundancy between them. Before deploying anything, formal training and official Red Hat certification for every member of the team: a platform only the person who installed it understands is a platform with a single human point of failure. I coordinated everyone involved, from the vendor to the internal systems and security teams.
03 · The outcome
Service live and the first application inside
The platform went live, redundant across data centres and with a certified team to operate it. The first application was containerised and migrated, which was the goal of the initial phase: to prove the path with a real case before opening it to the rest of the organisation. The investment was planned and approved for the following four years.
Identity governance at a banking institution
Same methodology, a different bank and a different subject: who can access what, and who answers for having authorised it.
01 · The challenge
Bringing in identity management where there was none
Rolling out an identity management and governance platform (SailPoint IdM) at a banking institution. Access control is one of the heaviest items in an audit: you have to be able to show who holds each permission, who approved it and when it was last reviewed.
02 · The approach
The recipe that had already worked
I applied the method from the previous projects: cost plan and multi-year horizon before buying anything, training and certification for the team before deploying, and coordination of all three fronts — vendor, systems and security — from day one. The difference from an infrastructure project is that the main counterpart here is not technical: the owners of the permissions sit in the business.
03 · The outcome
Access governed and auditable
The platform was implemented and operated by a trained team, with the processes for granting, reviewing and revoking access documented and defensible in an audit.
Privileged accounts out of obsolescence
Privileged accounts are an organisation’s master keys. When the platform that holds them goes out of support, the problem is not the version number: it is that the only defence against improper access now runs on unsupported software.
01 · The challenge
A credential vault with no support and no redundancy
A full migration of the privileged access platform (CyberArk) because of obsolescence. On top of losing support, the service had no high availability: if it went down, administered access to the critical systems went down with it.
02 · The approach
Migrate and make it redundant in one move
The same method: inventory and dependencies first, windows negotiated with the owner of each system, tested rollback. And, as with the server migration, use the outage to fix what was already wrong: the platform was not moved as it stood, it was redesigned with high availability.
03 · The outcome
A supported platform with no single point of failure
The platform ended up on a supported version and in high availability, and privileged accounts went back under custody that stands up in an audit.
The data loss prevention platform
Migration of the data loss prevention (DLP) platform and all of its components, at another banking institution.
01 · The challenge
A control you cannot switch off
DLP is not a standalone application: it is consoles, servers, endpoint agents and business rules built up over years. And it is a compliance control: while the migration runs, the institution cannot be left without oversight of the information leaving it.
02 · The approach
Both platforms running side by side
The usual method: inventory of components and dependencies, negotiated windows, tested rollback. The difference here is that both platforms had to coexist through the transition, so that no protection policy went unenforced for a single day.
03 · The outcome
A complete migration with no gap in coverage
Every component migrated and every policy transferred and verified, with no window in which information was left uncontrolled.
SIEM migration and rollout
The SIEM is the system that collects and correlates security events across the whole organisation. It is, quite literally, what you see with.
01 · The challenge
Moving the eyes without going blind
Migrating and rolling out a SIEM means moving event sources, correlation rules and dashboards across the entire perimeter. And doing it without the security team losing visibility during the transition, because a gap in collection is a gap in the ability to detect.
02 · The approach
Source by source, with the old one still running
Inventory of sources and rules, phased migration with both platforms collecting in parallel, and verification that every rule still fired on the new one before switching the old one off. Coordinated with the teams that own each event-emitting system.
03 · The outcome
Platform deployed, visibility unbroken
The SIEM was migrated and rolled out, with sources and rules transferred and verified, and no period of lost visibility.
Microsoft Purview rollout and go-live
Before you can protect information you have to know what information you hold, where it is and how much it matters. That is what this project was about.
01 · The challenge
Naming and labelling the information
Rollout and go-live of Microsoft Purview: discovering, classifying and labelling the organisation’s information and applying protection and retention policies to it. A project that stands or falls on the part that is not technical, because classification has to be validated by whoever owns the data.
02 · The approach
Classify with the business first, automate second
The classification and labelling scheme was agreed with the information owners before the tool was touched. Phased rollout starting with the most sensitive areas, coordinated with security and the end-user computing teams. Policies were switched on in audit mode first and only then in blocking mode, so that a badly calibrated rule would not break anyone’s work.
03 · The outcome
Platform live and policies enforcing
Purview deployed and running, with a labelling scheme agreed with the business and protection and retention policies applying to the classified information.
Local and perimeter firewall migration
Three different vendors — Check Point, Palo Alto and Fortinet — with the organisation’s perimeter in between. There is no comfortable maintenance window here: if it goes down, everything goes down.
01 · The challenge
Years of accumulated rules, across three technologies
Migration of the local and perimeter firewalls running on Check Point, Palo Alto and Fortinet. A long-lived firewall accumulates hundreds of rules whose original reason nobody remembers any more, and none of them can be removed blind: any one may be holding up a service used once a quarter.
02 · The approach
Translate the rules, do not copy them
Inventory of rules and their real dependencies before translating anything, because there is no automatic equivalence between vendors: what is one rule on one platform is three or none on another. Phased migration with traffic validation at each cutover and a rollback ready. Coordinated with the network and security teams and with the owners of the affected applications.
03 · The outcome
Perimeter migrated and the rule set cleaned up
Firewalls migrated across all three technologies, with the rule set reviewed and pruned along the way: the migration also served to retire what was no longer protecting anything.
XDR rollout across endpoints and servers
Detection is no longer about watching one place. An XDR correlates what happens on the endpoint, the server and the network, and responds without waiting for someone to look.
01 · The challenge
A new agent on every machine in the organisation
Rollout of Palo Alto Cortex XDR. The difficulty in a project like this is not the console: it is deploying an agent onto thousands of workstations and servers without degrading performance or blocking legitimate applications, and without users noticing that the machine changed underneath them.
02 · The approach
Pilot, false-positive tuning and wave-by-wave rollout
A pilot on a controlled group to measure impact and clear false positives before touching production. Rollout in waves, starting with the lowest-risk profiles, with policies in detection mode first and only then in prevention mode. Coordinated with security, systems and the end-user computing owners.
03 · The outcome
Full coverage and automated response
The platform was rolled out across the estate, prevention policies active and the security team running response from a single console.
What they have in common
None of them started with execution. Every one began with a service-by-service analysis — scope, dependencies, risks, business impact, availability requirements and rollback plan — and that analysis was signed off with every stakeholder involved in each service before anything was touched. It is the work nobody sees, and it is what decides whether a project lands or turns into a run of surprises.
Once that is approved, the rest is always the same: inventory and dependencies before anything moves. Training the team before deploying. Windows negotiated with whoever owns the service, not imposed on them. A tested rollback before touching production. And using every outage to fix what was already wrong, because the next opportunity takes years to come round.
If you have a project like these ahead of you — or an AI or compliance project in a regulated environment — write to me and we can talk it through. You can also read my full background.
