There is a version of cybersecurity advisory that looks like this: a consultant arrives, reviews a framework, produces a gap analysis, and leaves a slide deck behind. The organisation files it. Nothing changes.
That is not what we do at ContrailRisks.
The engagements we find most meaningful — and most consequential — are the ones where an organisation is already in motion. Where the strategic direction is clear but the path to get there is genuinely complex. Where the real security challenge is not "what should we build?" but "how do we stay secure while we build it?"
This is the nature of technology transformation risk. And it is, in our experience, one of the most underserved areas in enterprise cybersecurity advisory.
The Problem with Transformation-Era Security
Large organisations undergoing technology modernisation programmes share a common pattern. The target architecture is well-considered. The business case is clear. The roadmap is defined. What is rarely defined with equal rigour is the security posture during the transition itself — the multi-year window between the legacy estate and the destination state.
During that window, several things happen simultaneously that compound security risk.
Legacy systems that were manageable in a stable environment become acute vulnerabilities when institutional attention shifts to the transformation. The engineers who know them best are redeployed. Workarounds that were acceptable short-term become long-term fixtures. Compensating controls degrade as the infrastructure they rely on ages out.
Identity and access management — always the hardest domain to keep clean — gets genuinely messy during migrations. Access rights accumulate. Role definitions drift between old and new systems. Contractor accounts that were created for a specific project phase linger long after that phase is complete.
Governance models that work at steady state reveal their gaps under the pressure of change. Federated security models — where responsibility is split between a central group function and local entities — depend on clear accountability boundaries. Those boundaries blur during transformation. The question of who owns what, mid-migration, is often answered too late.
And all of this happens while engineering teams are already stretched. In most of the organisations we work with, between 40 and 50 percent of engineering capacity is consumed by run activities before a single transformation workstream begins. Security improvements must be delivered without destabilising core operations. That is not a minor constraint — it shapes every advisory recommendation we make.
What Good Advisory Looks Like in This Context
In a recent engagement with a large financial institution undergoing exactly this kind of structural transformation, we were asked to provide cybersecurity advisory support to the CIO and CISO. The organisation was integrating a local technology estate into a broader group platform, retiring a mainframe, rolling out AI productivity tools, and navigating a federated security operating model — all simultaneously.
Here is what substantive advisory looked like in practice.
Closing the Legacy Authentication Gap Without Waiting for Retirement
The organisation had a set of applications that could not support modern authentication mechanisms. No source code. Vendor lock-in. No ability to retrofit MFA. The previous mitigation — running these applications inside a virtualised containment environment — was reaching the end of its effective life.
The standard advisory response to this problem is to accelerate the retirement timeline. That is often the right long-term answer. But it is not an answer to the risk that exists today.
The approach we recommended draws on Zero Trust architecture principles. By placing a Policy Enforcement Point (PEP) in front of the legacy application at the network layer, an organisation can intercept user access and enforce MFA through an existing Identity Provider — without modifying the application at all. The application never needs to be MFA-aware. The user authenticates through the modern identity stack. Traffic is encrypted in transit. The security posture improves materially, and it does so on a timeline measured in weeks, not years.
This is not a theoretical approach. It is a well-documented pattern in the Zero Trust literature and one that is increasingly deployable through commercial and open-source tooling. For organisations with legacy estates that cannot be immediately retired, it is often the most pragmatic path to closing a live authentication gap.
Managing Security in a Federated Model
The organisation's security operating model split responsibilities between a central group function and a local security team. The group managed endpoint protection, security tooling, and global policy. The local team owned identity and access management, application-level security, and regulatory compliance.
This model is rational and common. The risk it creates is equally common: accountability gaps at the seams.
During a migration, the question of who owns IAM integrity as an application moves from a local system to a group platform often has no clear answer. In our experience, this is precisely where security incidents originate — not from sophisticated attacks, but from access rights that were not properly deprovisioned, from contractor accounts that were not offboarded when a project milestone passed, from role assignments that were copied from the legacy state rather than reassigned from the destination state.
Our advisory recommendation was to build a transformation-specific RACI for security and IAM — distinct from the steady-state model — and to make that document a precondition for each migration wave, not an afterthought. This is unglamorous work. It is also among the highest-value interventions available in a federated transformation environment.
Governing AI Before It Governs You
The organisation was rolling out AI productivity tools — both for general office use and for software development — ahead of a mature governance framework. Engineers were already using these tools to automate significant portions of their coding workflow.
In a general commercial context, the primary risk of AI tooling is code quality and subtle vulnerability introduction. In a regulated financial services context, the primary risk is different: data classification. What data are engineers feeding into these tools? What are the implications for client confidentiality, for data residency requirements, for regulatory obligations around sensitive information?
Our recommendation was not to slow the rollout. That battle is rarely worth fighting, and the productivity benefits are real. The recommendation was to ensure that governance caught up with adoption before it scaled further — through a mandatory Acceptable Use Policy framed as engineering norms rather than compliance documentation, and through data classification guardrails embedded into the AI tools and development communities already in place.
One point that emerged clearly from this engagement: AI governance that reads like a policy document will be ignored. AI governance that reads like a sensible set of professional norms, authored by engineers for engineers, will be followed.
The Broader Principle: Calibrate to the Transition, Not the Destination
The single most important insight we bring to technology transformation engagements is this: the security programme must be calibrated to the transition window, not the destination state.
Most security strategies are written with the target architecture in mind. That is appropriate for long-term planning. It is insufficient for managing the risk that exists today, in systems that are running right now, serving real customers, and processing real data.
The gap between current state and destination state is where organisations are most vulnerable. It is also where advisory support is most valuable — because the decisions made during that window have consequences that persist long after the transformation is complete. Access rights granted loosely during a migration become the foundation for future privilege creep. Legacy systems left inadequately controlled during a retirement programme become the entry points for incidents that occur after they were supposed to be gone.
Getting this right requires advisors who have navigated these transitions before. Who understand the operational constraints — the capacity limits, the cultural dynamics, the federated governance complexity — as well as the technical architecture. Who can translate sound security principles into practical, sequenced recommendations that engineering teams can actually implement without derailing the transformation they are trying to deliver.
What ContrailRisks Offers
ContrailRisks provides senior-level cybersecurity advisory and virtual CISO (vCISO) services to organisations navigating strategic risk, regulatory complexity, and technology change.
We work most effectively with CIOs, CISOs, and executive teams who need a trusted external perspective — one that is grounded in practical experience, calibrated to their specific context, and free from the vendor incentives that often distort advisory at this level.
If your organisation is in the middle of a technology transformation and you are not confident that your security posture is keeping pace with the change, we would welcome the conversation.
ContrailRisks is an independent cybersecurity advisory firm. All client work is conducted under strict confidentiality. Case material referenced in this article is used with appropriate anonymisation.
Fabrizio Di Carlo is the founder of ContrailRisks, a boutique cybersecurity and resilience advisory firm based in Berlin. He works with technology companies and regulated organisations on security strategy, governance, and regulatory compliance.