What 19 Years in IT Taught Me About Cybersecurity, Cloud, and DevOps

Most people treat cybersecurity, cloud engineering, and DevOps as three separate career paths. You pick one, specialise, and build from there.

After 19 years in enterprise IT — the last decade as the sole owner of cybersecurity posture, cloud transformation, and IT governance for a regulated financial services organisation — I am not sure that separation holds up in practice.

What the Work Actually Looked Like

For most of that decade, I was not a specialist in one discipline. I was accountable for outcomes across all of them.

Cybersecurity meant owning the risk register, managing the security posture, and reporting directly to the board. Cloud meant leading the organisation's migration from on-premise infrastructure to cloud services. IT governance meant being the person responsible when something broke, or when the regulator came asking.

None of those things exist in isolation. A cloud misconfiguration is a security incident. A governance failure is often an infrastructure failure. A security control that breaks a deployment pipeline is a DevOps problem.

The disciplines are different vocabularies for the same underlying system.

What 19 Years Actually Taught Me

The most useful thing I learned is not a specific technology. It is how to think about systems under pressure.

When something breaks in a regulated environment, the question is never just "what broke?" It is: what was the control that should have caught this? Why did it not? What do I tell the board on Monday?

That framing — accountability, traceability, communication under pressure — transfers directly into security operations work. It transfers into incident response. It transfers into designing infrastructure that is auditable by default rather than retrofitted for compliance after the fact.

Experience does not replace technical depth. But it changes how you apply technical depth. A junior engineer might know the same Terraform commands I know. They probably do not know what it feels like to explain a cloud architecture decision to a board audit committee, or to own a security incident across a live production environment with regulatory implications.

Why the MSc and the Internship

The MSc Cybersecurity from Robert Gordon University and the DevOps Micro-Internship at The CloudAdvisory Oy were deliberate choices to close the gap between what I had done at a strategic level and what I needed to demonstrate at a hands-on technical level.

The internship in particular has been direct and practical: build a three-tier AWS deployment, provision infrastructure with Terraform, set up CI/CD pipelines, run a security audit with agentic tooling. Real deliverables, not coursework exercises.

What I found is that the operational instincts from financial services transfer well. Knowing why you need private subnets for an RDS instance is not just a technical answer — it is the same instinct that makes you ask "what happens if this is breached?" before you build, not after.

The Combination That Is Rare

Cloud engineers who have never operated in a regulated environment often underestimate compliance and governance requirements. Cybersecurity professionals who have not built infrastructure often treat developers as the adversary rather than a shared stakeholder. DevOps engineers who have not worked at board level often do not know how to communicate risk in terms that drive decisions.

I am not claiming to be the best at any single one of those things. I am claiming that having done all three — with accountability, not just exposure — is a genuinely uncommon combination.

That is what 19 years actually taught me.