My career started in infrastructure and network engineering, which gave me a strong understanding of how technology environments are actually built and operate. From there, I moved into cybersecurity and progressively worked across identity and access management, privileged access management, enterprise security, cloud security, security engineering and product security.

That progression has been important to my development as a technology leader because I have not experienced security only from a governance perspective. I have worked closer to the technology itself—understanding infrastructure, networks, identities, applications, access, cloud environments and the security capabilities that connect them.

My experience across Vodafone Idea, Amdocs, Tata CLiQ and Tanla Platforms has also exposed me to very different technology and business models. Today, at Tanla Platforms, working in the CPaaS environment adds another dimension because technology is directly connected to large-scale digital communication and customer-facing business services.

Over time, my perspective has moved from securing individual components to understanding the technology ecosystem as a whole.

When I receive information about a problem, I process it with what I call a 360-degree approach. I want to understand its architectural impact, business impact, dependencies, existing capabilities and possible consequences before deciding what technology or control is appropriate.

That is how I see my role today: not simply as a cybersecurity professional, but as a technology leader who brings deep cybersecurity expertise into technology and business decisions.

What attracted me to cybersecurity was the technical challenge of understanding how systems can be broken, protected and continuously improved.

Cybersecurity exists because there are innovators in the wrong team who attempt to break the system. That makes the field fundamentally different from many technology disciplines. The technology keeps changing, but the underlying challenge remains: understand the system, understand its assumptions and find ways those assumptions can fail.

My own journey through infrastructure, networks, identity, privileged access, cloud and security engineering reinforced that perspective. Every layer introduced a different way of thinking about technology and risk.

Identity, for example, is not simply about managing user accounts. It determines who can access what, under which conditions and with what level of privilege. Similarly, cloud security cannot be treated simply as putting traditional security controls around cloud infrastructure. The architecture, trust relationships, workloads, identities and operating model are different.

That continuous change is what keeps me interested.

I also enjoy the builder side of technology. I have worked on and built security-focused technology outside traditional enterprise implementations, which gives me an opportunity to think about security from the perspective of someone designing a solution rather than only consuming one.

For me, cybersecurity remains interesting because it requires both technical depth and the ability to understand the larger system.

Working across different organizations has taught me that technology decisions cannot be separated from business context.

Telecommunications, retail, software services and CPaaS have different architectures, operational models and business priorities. A security solution that makes sense in one environment may not necessarily be the right answer in another.

My earlier infrastructure and network experience taught me to understand the technology foundation. My subsequent work in cybersecurity, IAM and PAM taught me how identity and access become fundamental components of enterprise architecture. Cloud and security engineering expanded that perspective further, while product security made me think about security as something that needs to be considered as technology is designed and delivered.

One lesson that has stayed with me is that organizations often respond to every new problem by introducing another tool.

I challenge that approach.

Before adding technology, I want to understand what capabilities already exist, whether they can be integrated, extended, upgraded or automated, and what complexity a new product will introduce.

That is also how I approach leadership. I try not to give people a solution before helping them understand the problem. If someone can learn to connect architecture, technology, risk and business impact, they become capable of solving problems independently.

My leadership has therefore evolved around two things: understand the system and develop the people who operate it.

The achievements I value most are the ones where a security capability moves from being a fragmented or reactive function toward becoming a mature technology capability.

My work across areas such as identity, privileged access, enterprise security, cloud security and security engineering has reinforced that transformation is rarely about deploying one product. It involves understanding the current architecture, identifying weaknesses, redesigning processes and controls, integrating technologies and making the resulting capability sustainable.

Identity is a good example. An identity program can easily become an exercise in provisioning accounts and conducting access reviews. At an architectural level, however, identity influences authentication, authorization, privilege, application access, cloud resources and ultimately the organization's trust model.

Similarly, security engineering needs to move beyond individual controls and consider how security capabilities work together.

That is why I measure transformation by the capability created, not simply by the technology deployed.

I am also particularly interested in reducing unnecessary complexity. If an organization already owns a capability that can solve a problem through integration or automation, adding another product may actually make the environment harder to secure.

The achievement I am proudest of, therefore, is helping move security from a collection of controls toward an integrated technology capability that can support the business.

I see these technologies converging rather than developing as separate security disciplines.

Zero Trust, cloud and AI all challenge the traditional assumption that we can establish trust based primarily on where something is located. As applications, workloads, users and AI systems operate across distributed environments, identity and context become much more important.

Identity is increasingly becoming a technology control plane. The question is no longer simply whether a user has access. It is whether the identity, device, workload, application or AI agent should be trusted for a particular action at a particular point in time.

Cloud further accelerates this shift because infrastructure becomes programmable and highly dynamic. Security therefore has to become equally dynamic. Controls need to be integrated into the architecture and operating model rather than added after deployment.

AI introduces an even larger change.

I think of AI as a modern Mjölnir—capable of striking down threats or shattering defenses. The problem is that the tool itself cannot decide who is worthy to wield that power. That judgment has to come from cybersecurity, governance and leadership.

Over the next five years, I expect security engineering to increasingly focus on securing machine identities, AI-enabled workflows, cloud workloads, APIs, data flows and automated decision-making.

The organizations that succeed will be those that treat security as part of technology architecture rather than as a separate protective layer around it.

One of the biggest challenges is technology complexity.

Organizations are adopting cloud platforms, SaaS applications, APIs, AI, automation and increasingly distributed architectures while simultaneously accumulating security products. The result can be an environment with multiple overlapping controls, fragmented visibility and considerable operational complexity.

My first response is therefore not always to buy another security product.

I ask what we already have.

Can an existing platform be extended? Can two capabilities be integrated? Can automation eliminate the problem? Can an architectural change address the root cause rather than adding another control?

This is particularly important as organizations adopt AI. AI introduces new data flows, identities, integrations and decision points. Securing it cannot simply mean adding an "AI security tool." Organizations need to understand where AI is being used, what information it can access, how it interacts with existing systems and what happens when those interactions become automated.

The other major challenge is the growing speed of technology adoption.

Security teams cannot become the function that continuously says no. They need to understand the technology well enough to say how something can be done safely.

That requires security leaders who can speak the language of architecture, cloud, identity, applications and business—not only the language of controls and compliance.

I start with the technology and business problem rather than the security product.

If a team proposes a new security capability, I want to understand what problem it solves, where that problem originates, what existing capabilities are available and what the technology will change in the environment.

For example, an identity investment can create value beyond access security. It can improve authentication, reduce excessive privilege, simplify user access, strengthen governance and support Zero Trust. The value is therefore distributed across security, technology operations and the business.

The same principle applies to cloud security. Rather than measuring success by how many security controls are deployed, I look at whether the architecture enables the business to use cloud capabilities safely and at scale.

I also consider the cost of complexity. A new security product may address one risk while introducing another layer of integration, administration, skills and operational dependency.

My 360-degree approach asks:

Does it reduce meaningful risk? Does it improve the business? Does it solve an existing problem? Can we achieve the outcome with something we already have? Does it introduce another problem?

ROI in cybersecurity is therefore not simply about avoiding an incident. It is also about enabling technology, reducing operational friction, improving resilience and getting more value from capabilities the organization already owns.

I believe enterprise cybersecurity will increasingly disappear into technology architecture.

That does not mean security becomes less important. It means security becomes less dependent on separate layers of controls added after technology is built.

Identity should be part of architecture. Cloud security should be part of cloud engineering. Product security should be part of product development. AI security and governance should be considered as AI capabilities are designed and deployed.

I want to contribute to that transition.

My vision is for security engineering to become an enabler of technology—helping organizations adopt cloud, AI, automation and digital platforms with confidence rather than creating friction around them.

But technology does not operate itself. People remain the most important part of the system.

I have been fortunate to have managers who mentored me and changed the way I think. I try to create the same impact for the people I work with. My greatest satisfaction comes from helping someone overcome a difficult problem, see it from another perspective and eventually become capable of solving similar problems independently.

Technology leadership, to me, is therefore about building two things simultaneously: better technology and better technologists.

If the people I have worked with become stronger thinkers and the technology environments become more capable, secure and resilient because of my contribution, that is the legacy I want to leave.