Why I Left Every Cybersecurity Job I Ever Had
“So, why did you leave your last job?”
It’s everyone’s favourite interview question, right?
Naturally, you’re expected to offer a diplomatic answer about pursuing new opportunities, seeking greater challenges or feeling ready for professional growth.
All perfectly reasonable answers, I suppose...also rather “fluffy”, IMO.
Now, I’m far from diplomatic…so my honest answer is a little less polished:
I got tired of being invited to assess cybersecurity risk after everyone had already decided they didn’t want to hear about the risk.
This wasn’t unique to one employer or one project. It was a recurring theme throughout my cybersecurity career, particularly on large technology projects.
Here’s how it went (despite my team’s and my ongoing efforts to change things):
Cybersecurity would usually be invited in at one of two points:
The first was at the very beginning, when the project was still a collection of ideas, tentative diagrams and blank boxes labelled “security needed here.”
I would provide a blanket list of security requirements, controls and design considerations. Everyone would nod thoughtfully. The document would be saved somewhere important. Good job!
Then the project would continue for another 12 months without me. No amount of groveling to be let in on the status ever worked! (exceptions to a couple of amazing PMs I worked with - I think you know who you are)
The second invitation would arrive near the very, very end.
Like, project deliverables three-quarters of the way across the finish line.
And someone would suddenly remember:
“Oh, right. Cybersecurity needs to sign off! I’ll just run it past them for a quick checkmark.”
Oh boy…
That rarely meant they wanted a meaningful risk assessment.
It was a request to provide a signature.
Preferably without finding anything.
Cybersecurity cannot protect a project it isn’t allowed to influence
Being consulted at the beginning of a project is useful. It helps establish requirements and identify obvious design concerns.
But one conversation at the beginning is not security integration.
Projects evolve.
Requirements change. Vendors reveal limitations. Timelines tighten. Budgets shrink. Technical teams make decisions to keep the project moving. A control that looked perfectly sensible on a diagram may become unworkable when it meets an actual operator, asset or production environment.
This is especially important in operational technology.
In an IT environment, a poorly designed security control might frustrate an employee or interrupt a business process.
In an OT or industrial control system environment, availability, reliability and SAFETY are fundamental. The people operating these systems are responsible for keeping physical processes running. If a security solution prevents them from doing that, they will find another way.
And honestly?
They often should.
Because of an operator cannot access a system to stop a critical process because of a new cybersecurity-initiated control, they’re going to find another way in.
And they do.
Let me make this VERY CLEAR: That isn’t evidence that operators “don’t care about security.”
It is evidence that the security design did not adequately account for operational reality.
The project that became my final straw
In 2020, I was brought into an operational technology project shortly before implementation.
The team had designed a remote-access solution for an OT control systems environment. I was told that the project was essentially complete and needed a QUICK cybersecurity design review so it could receive final approval.
The planned go-live date was approximately four weeks away.
No pressure, then.
As I began reviewing the detailed design and speaking with the people involved, I found something far more important than a missing line in a compliance checklist.
The approved remote-access solution wasn’t reliably meeting the operational team’s needs.
So people had created alternative ways into the environment.
The design documentation showed one controlled path. Operational reality contained a few others.
Those alternate paths weakened the intended security architecture and created access risks that needed to be understood before the project went live.
But more importantly, the new solution prevented the operators from doing their jobs, a large part of which was protecting the safety of workers, materials and property.
This wasn’t a small issue. Or one to brush under the rug with a “quick” cybersecurity sign-off.
Sure, remote access into an OT environment can introduce significant risk. Depending on how it is designed, it can affect network segmentation, authentication, authorization, monitoring, vendor access and the organization’s ability to detect or revoke a connection.
But, a secure front door doesn’t provide much comfort when people need the side window to do their jobs.
So, of course, I voiced my concerns and noted the findings.
The response wasn’t curiosity about why the workarounds existed or how we could redesign the solution to support the operators more effectively.
Instead, the conversation became a negotiation over whether the risks really needed to count.
Could the wording be softened?
Was the likelihood truly that high?
Were the existing controls perhaps good enough?
Could the risk be accepted temporarily?
Was I being overly cautious? Or ridiculous?
The project had a deadline, after all.
I understood the deadline. I always understand the deadline.
A strong cybersecurity professional should understand that organizations have projects to deliver, customers to serve and operations to maintain. Our role is not to sweep into a meeting wearing a dramatic black cape, declare everything too dangerous and disappear into the night.
Our role is to help the business move forward with an informed understanding of risk.
But “the project is almost finished” does not change the architecture.
A deadline does not close an undocumented access path.
A green status report does not make an ineffective control effective.
And calling something an acceptable risk before it has been properly analyzed does not make it one.
Eventually, I found myself in a meeting with the project manager and sponsor where the discussion stopped being about the design.
My judgment, professionalism and intelligence became the topic instead.
The message was clear: the project needed to proceed, and my assessment was making that inconvenient.
That meeting became my final straw.
Not because someone disagreed with me. Cybersecurity professionals should expect disagreement. Risk assessment depends on examining different perspectives, challenging assumptions and making decisions under imperfect conditions.
I left because I could no longer lend my professional credibility to a process that wanted cybersecurity approval without cybersecurity scrutiny.
My integrity wouldn’t allow it.
A cybersecurity audit and a risk assessment are not the same thing
Part of the problem was a misunderstanding I have seen repeatedly throughout my career.
Organizations often treat a cybersecurity risk assessment as though it were an audit.
An audit typically asks:
Is the required control documented?
Has it been implemented?
Is evidence available?
Does the environment comply with the applicable standard, policy or requirement?
Those are necessary questions. But notice how they’re all Yes/No?
A risk assessment goes further:
Does the control actually reduce the intended risk? How?
Does it work in this particular architecture? What is the full design? Execution of the process?
Can the people responsible for operations use it reliably? Does it open opportunities for backdoors or other risks?
What happens when it fails?
What assumptions were made when it was selected?
Have changes to the design created new exposure? How has the design been holistically evaluated?
Are there alternate access paths?
Could one control failure undermine several others?
What are the consequences in this specific operational environment?
Is the remaining risk understood by someone with the authority to accept it?
I can, and do, use audit standards, control frameworks and security requirements during an assessment.
But I don’t stop at confirming that a control exists.
I follow it into the actual environment.
I look at how the application communicates, how the network is segmented, how identities receive access, how vendors connect, how information moves and how people complete their real work.
Then I look for the gaps between the documented system and the functioning one.
That gap is where some of the most consequential risks live.
The best time to find a security problem is while it is still inexpensive
This is why I believe cybersecurity professionals should be involved throughout a project, not stationed at the beginning or summoned at the end.
When I am part of the process, I can notice a deviation while it is still a conversation.
We can ask why the design is changing. We can assess the new risk. We can work with the engineers, operators, vendors and project team to find an alternative. We can document the decision. We can keep the project moving.
Finding the same issue four weeks before implementation turns it into an emergency.
Now the organization may need to change a completed design, renegotiate with a vendor, delay implementation or formally accept a risk it never intended to create.
That isn’t happening because cybersecurity “held up the project.”
It is happening because the project carried an unresolved security issue forward until there was almost no room left to address it.
Early involvement protects the architecture.
Ongoing involvement protects the timeline.
Why this makes me good at OT cybersecurity risk assessment
I am not interested in dropping a generic control framework onto an environment and declaring everything that doesn’t fit a deficiency.
OT cybersecurity requires more judgment than that.
The controls must account for the reality of the environment: legacy assets, uptime requirements, vendor dependencies, remote locations, limited maintenance windows, specialized protocols, safety considerations and equipment that may remain operational for decades.
A technically impressive control that prevents operators from doing their jobs will not remain an effective control for long.
Someone will bypass it - and I can’t blame them.
The better approach is to understand the operation deeply enough to design security that people can actually use, and to identify where the business may be accepting more risk than it realizes.
That is how I think when I assess an application, network design or industrial control system environment.
I don’t only ask whether a security control is present.
I ask whether it works.
I ask what it depends on.
I ask how it fails.
I ask what the operator does at 2:00 a.m. when the approved process doesn’t work and production still needs to continue.
And I ask whether the people signing the risk acceptance understand the system that exists in practice, not simply the one represented in the final design document.
So, why did I leave my last cybersecurity job?
Because I was hired to identify risk, and then pressured to make the risk less inconvenient.
These days, I’m much more interested in working with organizations that want cybersecurity to shape better decisions not simply bless decisions that have already been made.
Because cybersecurity is most valuable before the sign-off page.
And a risk assessment should never be treated like a rubber stamp with a CISSP attached.
