ProBackend
access management iam security
2 hours ago5 min read

Why Every Security & Compliance Analyst Must Think Like an Operational Engineer

A look at the imperative for aligning governance, risk, and compliance with hands-on security engineering, featuring insights from BNSF's Yelena Mujibur Sheikh.

Why GRC Cannot Survive in a Silo

Checklists are dead. Let's be honest: if your security status is just spreadsheet templates and signoff sheets, you aren't protected. You're just ready for an auditor's stamp.

For a long time, governance, risk, and compliance operated in a comfortable vacuum. One team wrote the policies, another built the infrastructure, and a third tried to make sure the two didn't crash into each other. That model fails immediately in a complex operational setting. Take critical transit networks. When you are securing logistics and heavy rail at BNSF Railway (https://www.bnsf.com/), physical risk and digital risk merge. If a routing control system goes down, it's not a lost SaaS login. It's trains sitting on a track.

Yelena Mujibur Sheikh, a Cybersecurity Engineer II at BNSF, represents the breed of engineer who bridges this gap. GRC is not about ticking boxes; it's about translating operational real-world risks into hard engineering requirements. If compliance parameters aren't baked directly into the engineering design phase, they become friction points that developers and system administrators actively work to bypass.

Why GRC Cannot Survive in a Silo

Transforming the Security & Compliance Analyst Role From Paper to Pipelines

This shift changes the role of the modern security & compliance analyst entirely.

Years ago, analysts looked at security through a rearview mirror. They gathered evidence after the fact. Today, a security & compliance analyst has to operate directly inside the engineering pipeline, checking things in real-time. In cloud-native and modern IAM infrastructures, the target is continuous assurance. You don't perform an access review once a quarter and call it good. You set up automated identity guardrails that enforce least privilege on every pull request.

If you're managing access management and IAM security, you're dealing with a system that shifts by the second. Developers spinning up temporary instances, pipeline tokens running automated builds, and third-party APIs requesting read-write access to corporate directories. If your analyst only knows how to read static policy documents, they are blind to the actual state of the system. They need to understand how groups, roles, and resource policies interact. Compliance has to become code. If a rule can't be expressed as a test pattern, it's not going to survive the speed of deployment.

Transforming the Security & Compliance Analyst Role From Paper to Pipelines

Bridging Critical Infrastructure and Controls at BNSF

Bringing GRC into heavy infrastructure like rail means dealing with massive legacy systems alongside cutting-edge integrations. The work Yelena Mujibur Sheikh does at BNSF showcases why you can't just apply generic IT templates to operational technology. Protecting freight transit networks and safety-critical signaling systems requires a deep understanding of physical risk.

It's about knowing how data moves across complex environments, from edge field units to centralized dispatch databases. If you don't grasp the underlying engineering of the line, you can't assess the risk properly. Sheikh’s thought leadership on infrastructure challenges has earned recognition in The Wall Street Journal. Risk oversight isn't a passive corporate function anymore—it's an operational necessity.

When systems are allowed excessive permission sets, the damage isn't localized. We've already seen the impact of broad, unchecked access when autonomous agents operate without limits, as in the PocketOS incident. If you don't design separate, hardened recovery boundaries, you leave your entire operation open to cascading errors. You can trace Rohan Kapoor's analysis on the necessity of air-gapped recovery systems to see how dynamic operations require immediate, decoupled protection. Checking a compliance box doesn't save your database from a run-away script; hard engineering boundaries do.

The Tooling Shift: Automating Configuration and Recovery

You can't do this with manual reviews. Not anymore.

Securing a modern environment means using tools that run checks constantly. Take the security & compliance analyzer veeam utility, for instance. It doesn't ask you once a year if your backups are encrypted or if your recovery sites are isolated. It scans the live configuration, flags risks, and tells you what doesn't match standard baselines. It's a control loop, not a spreadsheet.

In my work as a CSPM lead, I focus on the exact same problem: how to automate misconfiguration remediation. When a cloud access group drifts from the approved configuration, you don't file a ticket and wait for a meeting. You trigger a remediation flow to restore the baseline within minutes. If a compliance check is manual, it's too slow.

This applies to supply chain security, too. You can't rely on trust in software registries. As we saw from the ClawHub malicious skill discovery, static signature matching was completely fooled by simple evasion techniques. The registry looked clean, but the behavior was malicious. You need continuous controls that look at what code actually does, not what its metadata claims. Real-time compliance is the only way to manage a dynamic attack surface.

Shaping the Next Generation of Security Champions

We also have to change how we train people.

If the industry keeps churning out compliance specialists who can't read a YAML configuration file or a git history, the disconnect will keep growing. We need to build a new generation of security professionals who are comfortable in both worlds.

Mentoring and talent pipeline development are critical here. That's why community contributions like Sheikh's role as a scholarship judge for ISC2 (https://www.isc2.org/) are so important. We need to support new talent coming into the field, but we must guide them away from the static, checklist-focused training of the past. The goal should be to build analytical thinkers who can look at a system, understand the threat model, write the automated control check, and ensure it satisfies the high-level policy. That is how we build resilient systems. That is how we protect critical infrastructure.

It is time to stop viewing compliance as paper and start building it directly into the code. The engineers who get this are the ones who will protect the future.

More blogs