Today I will be sharing some news, mostly AI related and giving my thoughts and some actionable steps to mitigate risks. Things are happening in the AI space, and just generally in the tech space. Staying up to date gives you an edge, and as always, “Knowledge is power”.

Vulnerability in Claude Extension for Chrome Exposes AI Agent to Takeover

A vulnerability in the Claude extension for Chrome could allow attackers to take over the AI agent and abuse it for information theft, cybersecurity firm LayerX reports.

The flaw, dubbed ClaudeBleed, is a combination of lax permissions, where any Chrome extension can run commands in Claude in Chrome, and poorly implemented trust in the origin of the command, not the execution context.

According to LayerX, the main issue is that the Claude extension allows interaction with any script running in the origin browser, without verifying its owner.

“As a result, any extension can invoke a content script (which does not require any special permissions) and issue commands to the Claude extension,” the company explains.

Claude in Chrome, it says, trusts the origin of the execution, which is claude.ai, and not the execution context, thus allowing any JavaScript running in the origin to issue privileged commands.

This allows an attacker to create an extension with a declared content script and configured to run in the Main world, thus ensuring the script is executed as part of the page, and send a message to the Claude extension, which trusts the sender because it runs in claude.ai.

Because a message handler in Claude in Chrome accepts and forwards arbitrary prompts, the attacker can perform remote prompt injection and control the AI agent’s actions.

While Claude enforces user confirmation for sensitive actions, as well as policies that prevent certain actions, and makes decisions based on certain inputs, LayerX discovered that the attacker’s script could bypass these protections.

The company was able to forge user approval by repeatedly sending a confirmation message and relied on Document Object Model (DOM) manipulation to dynamically modify UI elements and alter Claude’s perception of the actions.

It was also able to gain visibility into command execution through repeated triggering of the action and by observing the effects.

“This vulnerability effectively breaks Chrome’s extension security model by allowing a zero-permission extension to inherit the capabilities of a trusted AI assistant,” LayerX says.

This attack chain, the company says, allows an attacker to weaponize Claude to exfiltrate data from Gmail, GitHub, or Google Drive, as well as to send emails, delete data, and share documents on behalf of the user.

When notified of the issue, Anthropic told LayerX it was working on a patch, but the fix only partially addressed the underlying vulnerability, through “internal security checks to prevent extensions running in ‘standard’ mode from executing remote commands”.

Because the root cause of the weakness was not addressed, an attacker can simply switch the extension to ‘privileged’ mode and bypass the fix. The user is never notified or asked to approve the switch, LayerX

My Thoughts

The story hits a perfect storm: a well-known AI brand, a catchy name, an incomplete patch, and implications that go well beyond one company. Here’s how to make the most of it.

When a security firm discloses a vulnerability and the vendor patches it within days, that should normally be the best-case outcome. With ClaudeBleed, it’s where the real story begins.

LayerX reported the flaw to Anthropic on April 27. Anthropic responded the next day, stating the issue had already been identified internally and would be fixed in an upcoming release. That response itself is worth unpacking. Saying it was “already identified internally” means Anthropic knew about a critical trust boundary failure in a product it had just shipped to the public. That isn’t a minor oversight buried in a backlog ,it’s a known, open wound in an AI agent with access to your Gmail, Drive, and GitHub.

Then came the patch. Anthropic released an updated extension version (version 1.0.70) on May 6, 2026. Contrary to their initial response, the externally_connectable message handler was not removed, but Anthropic did introduce additional approval flows for privileged actions. The researcher didn’t need days to find the bypass. LayerX’s principal security researcher said he was able to “hack the fix” within just three hours.

This matters beyond the specifics of one extension. A three-hour bypass tells you the underlying architecture was never properly rethought ,a surface-level guardrail was added on top of a fundamentally broken trust model. That’s a pattern the security community has a name for: “security theater.”

Zero permission = maximum damage

Chrome’s extension permission system is designed around a principle most users intuitively understand: before an extension can do something sensitive, it has to ask for it. Want to read your tabs? Ask. Want to access a specific site? Ask. This is the social contract that makes the Chrome Web Store feel (at least somewhat) trustworthy.

ClaudeBleed shatters that contract. Any extension can invoke a content script, which does not require any special permissions and issue commands to the Claude extension. The attack works because Claude in Chrome trusts the origin (claude.ai) rather than the execution context. Any JavaScript running on claude.ai can therefore impersonate a legitimate user command. A malicious extension simply needs to inject a content script configured to run in the “Main world,” meaning it executes as part of the page itself rather than in the isolated extension sandbox.

The practical consequence is stark. A zero-permission extension can inherit the capabilities of a trusted AI assistant meaning every dangerous capability Claude has been granted (reading your Drive, composing your emails, browsing your GitHub) becomes available to any extension that wants it, with no prompts, no warnings, and no trail. The malicious extension looks completely harmless in Chrome’s permissions UI because it literally has none.

Imagine a keycard system where any employee badge including the janitor’s automatically gains the same access as the CEO’s, simply by being swiped at the CEO’s door while the CEO is nearby. The badge has no special privileges on paper. The building’s security system just fails to check whether the badge actually belongs there.

The cover-your-tracks angle

Most cyberattacks leave footprints. Anomalous login times, unexpected file access logs, emails in “Sent” that the user didn’t write. Incident responders are trained to look for exactly these artifacts. ClaudeBleed makes that job dramatically harder.

Claude relies on text, user interface semantics, and interpretation of screenshots to make decisions all things that an attacker can control on the input side. The researchers modified Claude’s user interface to remove labels and indicators around sensitive information, like passwords and sharing feedback, then prompted Claude to share the files with an outside server.

Because Claude is making decisions based on what it perceives the page to say not what it actually says the attacker can reshape Claude’s understanding of reality. A “Share externally” button can be relabeled “Request feedback.” A file named “Top Secret” can be made invisible to Claude’s perception while still being exfiltrated. The AI doesn’t know it’s been deceived because it has no ground truth to check against.

Where there is visible activity, the model can be prompted to cover its tracks by deleting emails and other evidence of its actions. This creates a scenario where a full data exfiltration credentials, private documents, confidential communications could occur with no forensic evidence remaining. The victim would have no reason to suspect anything happened until they discovered, externally, that their data had been leaked.

This is what makes ClaudeBleed qualitatively different from a traditional credential-stealing attack. Traditional attacks are passive they capture what passes through. This attack is agentic it actively uses your trusted tools, speaks with your voice, and then erases the conversation.

The “AI race” frame

The most durable insight from this research isn’t technical ,it’s cultural. The LayerX researcher warned: “In the current AI race, vendors are moving too fast and granting powerful capabilities to improve user experience, while neglecting basic security foundations and opening new opportunities for attackers. As AI agents become the norm, these structural flaws are a ticking time bomb.”

This is worth examining carefully because it applies far beyond Anthropic. The commercial pressure to ship AI agents that do things book appointments, send emails, file tickets, manage calendars creates a direct conflict with the security principle of least privilege. An AI agent that can’t actually take consequential actions isn’t very impressive in a demo. An AI agent that can take consequential actions is, by definition, a high-value target.

The problem is that agentic AI collapses two things that traditional software kept separate: authentication and authorization. When you log into Gmail, you are authenticated as yourself and authorized to act as yourself. When Claude in Chrome accesses Gmail on your behalf, the authorization is implicit Claude inherits your authenticated session. There’s no separate token, no scoped permission, no audit trail of “Claude did this.” It’s just you, as far as Gmail is concerned.

This architectural shortcut is understandable in a world where AI agents are still experimental. It becomes dangerous the moment those agents touch production data at scale. ClaudeBleed is a case study in what happens when the shortcut gets exploited before the architecture gets hardened.

Claude Code OAuth Tokens Can Be Stolen Through Stealthy MCP Hijacking

An OAuth token with wide access rights can be stolen stealthily and largely undetectably from Claude Code.

Claude Code is an agentic system. This is great for developers but concerning for security teams. Agentic systems can expand the attack surface while operating largely invisibly. A major issue is the OAuth token. If an attacker can acquire this, the adversary effectively has a master key or digital proxy granting access to every tool connected to or accessible from the Claude Code MCP.

Mitiga Labs has identified an issue within Claude Code that would allow attackers to redirect output, including the tokens, to their own infrastructure before everything is sent on to the legitimate destination. It’s a classic man-in-the-middle-attack giving the attacker access to the tokens.

The MCP configuration and the OAuth tokens are stored in ~/.claude.json. If an adversary can modify that file, MCP traffic can be redirected through the attacker’s own infrastructure. Mitiga has published details of how this could be achieved.

The two prerequisites for the attacker is the ability to install a tailored npm on a machine where Claude Code is configured with dynamic authorization MCP servers. The NPM registers a lifecycle hook that runs as part of the install.

A post installation hook locates common clone locations, and populates the paths with a pre-configured trust dialog set to true. “No prompt will fire when the directory is later opened, because the flag the prompt is gated on is already set,” reports Mitiga.

The hook also opens ~/.claude.json and edits the MCP server in the global config file. It edits ‘mcpServers’ to include the proxy address. “This puts us, ‘the adversary’, in the middle of any request that goes out to the MCP server. As the attacker, we got mitmproxy configured and intercepting,” explains Mitiga.

Whenever Claude Code initiates or refreshes the MCP session, it connects to the proxy and the token transits to the attacker’s infrastructure. The user just sees a valid flow. If the user rotates the token, the hook writes it back on the next load. If the user edits the MCP URL, the hook loads it back on the next load. The attacker has achieved both stealth and persistence.

The attacker gets, “A durable redirection of the victim’s SaaS credentials into attacker-controlled infrastructure, with automatic recovery from token rotation, invisible to the victim’s endpoint UI, and indistinguishable from legitimate traffic on the provider’s side.”

As a man in the middle, the attacker can easily steal any OAuth token since it is stored in plain text within ~/.claude.json. Once stolen the attacker can use the token as an MFA-bypassing golden key into any tool to which the MCP connects, with the same permissions as the user.

Without care, the user sees nothing. No flags are raised since the MCP is simply doing what it is told to do, and the user isn’t aware these actions have been compromised. The new adage of assuming a compromise has happened should take center stage. “Monitor Claude Code configuration changes, MCP server URL changes, OAuth refresh behavior, suspicious SaaS API activity, and unexpected traffic through MCP integrations,” suggests Mitiga.

What you mustn’t do is wait for a solution from Anthropic. Mitiga reported its findings to Anthropic on April 10, 2026. On April 12, 2026, Anthropic replied it was ‘out of scope’. The reason given was effectively the same as its response to Adversa’s ‘TrustFall’ disclosure: the user has already consented to what might happen next.

My Thoughts

Unpacking the Technical Threat

The attack is elegant in the way the worst attacks always are it doesn’t break anything, it however redirects everything. A few specific angles worth developing:

The npm lifecycle hook as a delivery vector. The prerequisite is the ability to install a crafted npm package on a machine running Claude Code. This sounds like a high bar, but it isn’t. Supply chain attacks via malicious or typosquatted npm packages are routine. Developers Claude Code’s primary users install npm packages constantly, often without deep inspection. The attack doesn’t require a zero-day, a phishing campaign, or physical access. It requires one careless npm install from a poisoned repository, which is exactly how most supply chain compromises begin apparently.

The ~/.claude.json plaintext problem. OAuth tokens in plain text in a home directory config file is, to put it charitably, a design choice that prioritises developer convenience over security hygiene. Tokens of this sensitivity belong in OS-level credential stores macOS Keychain, Windows Credential Manager, Linux Secret Service where they benefit from access controls, encryption at rest, and auditing. The decision to use a flat JSON file means that any process, any script, any malicious package running as the same user has trivial read/write access. This isn’t a sophisticated exploit it’s just a file open.

The persistence mechanism is the most alarming part. Stealing a token is bad. Maintaining access through token rotation is a different category of threat. The hook writes the stolen config back every time the file is modified. The attacker effectively owns the MCP configuration in perpetuity. The standard remediation step for a stolen credential rotating the token is not just ineffective here, it is actively counterproductive. Every rotation becomes a fresh delivery to the attacker. This flips the power dynamic in a way that most security playbooks aren’t designed to handle.

MFA bypass as the downstream consequence. Modern security hygiene teaches users to trust MFA as a last line of defence. If a password is stolen, MFA saves you. OAuth tokens, however, are post-authentication artefacts they are issued after MFA was satisfied. Stealing an OAuth token means the attacker skips the entire authentication ceremony and arrives at the authorized state directly. Every tool connected to the MCP code repositories, cloud infrastructure, SaaS platforms, internal API becomes accessible without a single MFA prompt. The attacker is not breaking into your house; they are using your key, which you handed them unknowingly.

The invisibility is structural, not incidental. There are no anomalous login events because the token is legitimate. There are no unusual API calls because the attacker is operating with the user’s exact permission set. The MCP continues to function normally from the user’s perspective because the proxy forwards everything correctly it just reads it first. Traditional detection methods look for anomalies. This attack produces none. That structural invisibility is a design consequence of how agentic systems work, not a clever trick the attacker deployed.

The Bigger Issue In my Opinion: The “User Consented” Defence Is some BS!!

Anthropic’s “out of scope” response echoes its reaction to Adversa’s TrustFall disclosure. The logic, as best as can be reconstructed, goes: the user chose to install Claude Code, the user chose to configure MCP servers, the user chose to connect OAuth tokens therefore the user accepted the risks that follow. This is consent-as-liability-shield, and it deserves serious pushback. SOME ABSOLUTE BS!!!!!!

Consent requires comprehension. A developer configuring Claude Code understands they are connecting a powerful AI coding assistant to their tools. They do not understand because no documentation meaningfully conveys this that a single malicious npm package can then silently redirect their entire authenticated identity to an attacker’s infrastructure, persist through every remediation step they know how to take, and remain entirely invisible. Consent to use a tool is not consent to every attack vector that tool’s architecture enables. If it were, every vendor could simply disclaim responsibility for every vulnerability by pointing to the terms of service.

The “already consented” argument scales dangerously. If Anthropic’s position is that users who configure dynamic authorization MCP servers have accepted the risks of OAuth token interception, what exactly is Anthropic’s security team responsible for? This logic would exculpate any vendor from any design flaw, so long as the user had to configure something first. Security researchers and practitioners have spent decades pushing back against exactly this framing. The user consented to install software, not to have their credentials silently exfiltrated with persistence through rotation.

The user population matters. Claude Code’s users are developers. They are, relative to the general population, sophisticated. They understand command lines, configuration files, and package managers. If a developer installing npm packages in the normal course of their work cannot be expected to detect or defend against this attack, the attack is not within the user’s reasonable ability to manage. Pushing responsibility to users for attacks they cannot practically detect or remediate is a values statement about who the vendor thinks bears the security burden.

Compare to the industry standard. When a password manager stores credentials in plaintext and blames users for installing malware, we call that negligent design. When a browser extension exposes authentication tokens to other extensions and says users consented to the extension model, we publish CVEs. The “user consented” frame is applied inconsistently across the industry, and almost always in ways that benefit vendors rather than users.

The Broader Agentic AI Security Problem

This vulnerability is a useful case study in a structural challenge the industry has not yet seriously grappled with.

Agentic systems are valuable precisely because they act. An AI coding assistant that can’t run commands, call APIs, or interact with tools isn’t very useful. But every capability you give an agentic system is also a capability you give to anyone who can compromise that system. The attack surface of Claude Code is not just Claude Code it is every tool Claude Code can reach, with every permission the user has been granted, with no additional authentication step between them.

Traditional software has explicit attack surfaces: this binary, this port, this API endpoint. Agentic systems have contextual attack surfaces that expand and contract based on what the agent is configured to do. A developer who connects Claude Code to their AWS environment, their GitHub, their Jira, their Slack, and their production database has created an agent that, if compromised, yields access to all of those systems simultaneously. The OAuth token is not one key it is a keyring.

The MCP (Model Context Protocol) architecture specifically is worth examining here. MCP is designed to make it easy to connect AI agents to tools and services. That ease is the point Anthropic wants a rich ecosystem of MCP integrations. But ease of connection is the inverse of security of connection. Every MCP server added to a Claude Code configuration is another potential entry point, another set of credentials to protect, another attack surface to monitor. The architecture that makes MCP powerful is the same architecture that makes this attack possible.

What Defenders Should Actually Do

Treat ~/.claude.json as a sensitive credential file. Set file permissions to 600 (owner read/write only). Monitor it for unexpected changes using file integrity monitoring tools anything from basic inotifywait on Linux to enterprise endpoint detection tools. Any write to this file outside of an expected Claude Code configuration session should trigger an alert.

Audit npm install practices on developer machines. Implement policies around package provenance verify packages against known registries, use lockfiles, consider npm audit as a mandatory pre-install step. Treat developer workstations with agentic AI tooling as high-value targets deserving the same scrutiny as production servers.

Review MCP server configurations regularly. Know what MCP servers should be configured and what addresses they should point to. Any unexpected URL in mcpServers is a potential indicator of compromise.

Monitor OAuth token usage patterns for connected tools. If Claude Code is connected to GitHub, for example, set up alerts for API calls made with your OAuth token from unexpected IP addresses or at unexpected times. The attacker is using your token, but they are not you, therefore their usage patterns may differ from yours.

Scope OAuth tokens aggressively. Where possible, issue OAuth tokens with the minimum permission set needed for Claude Code’s legitimate use rather than broad account access. A token that can only read repositories is less damaging when stolen than one that can write, delete, and administer.

Do not wait for Anthropic. This bears repeating plainly. Mitiga reported this on April 10. Anthropic responded on April 12 with “out of scope.” There is currently no indication that a fix is planned. The attack works today. Mitigation has to come from defenders.

A Note on the Anthropic Response Pattern

This is now a pattern, not an incident. The TrustFall disclosure received a similar response. ClaudeBleed’s patch was bypassed in three hours. A CVSS 10/10 RCE in Claude Desktop Extensions was reportedly left unpatched. The emerging picture is of a vendor deploying powerful, widely-connected agentic systems while adopting a narrow definition of what constitutes its security responsibility.

This is not a unique failure. The AI industry broadly is in a period where speed to market and feature richness are rewarded, and security hardening is deferred. But Anthropic’s specific responses to specific disclosures are now a matter of public record. Security teams evaluating whether to deploy Claude Code in enterprise environments should weigh not just the technical capabilities of the tool, but the vendor’s demonstrated approach to vulnerability response. That is a legitimate and important input to procurement and risk decisions.

The adage Mitiga quotes assume compromise has already happened is the right posture. But it is worth adding: also assume that the vendor will not close the gap for you, and plan accordingly.

Closing

I hope you have found value in today’s article. Consider clapping, subscribing and following me on my socials.

• LinkedIn: https://www.linkedin.com/in/m49d4ch3lly
• Twitter: https://twitter.com/m49D4ch3lly
• Gmail: Umarfarouk037@gmail.com

Sources for this article @https://www.securityweek.com/

On May Day, Labour Day, of all days Tosin Eniolorunda, Co-Founder and Group CEO of Moniepoint, took to the stage and later, LinkedIn to deliver what read like a corporate TED talk on Nigeria’s talent crisis. The post has since gone viral in tech circles, generating a wave of approving nods from people who perhaps did not read it closely enough.

The part that is true

Tosin Eniolorunda is partly right about the talent gap, but he’s asking the wrong people to fix it, and conveniently ignoring his own role in the problem.

To be fair, Eniolorunda is not making things up wholesale. Nigeria does face a serious brain drain. The Japa wave is real. Senior engineers with payments infrastructure experience are genuinely scarce. Dangote has indeed complained publicly about talent shortages. These are legitimate structural problems.

There is also an ongoing rot steming from the consumption of content online, ala tiktok, instagram, twitter.

I also agree that there is the hookup culture, yahoo yahoo etc and the educational system is in decline.

There is also a role model problem, especially when you see politicians making blood money off the suffering of the masses.

But acknowledging a real problem is not the same as diagnosing it honestly and his diagnosis is riddled with contradictions, omissions, and a rather convenient scapegoating of structural forces that companies like his have helped create.

“Nigeria Doesn’t Lack Talent — It Lacks Honest Employers”

Every few months, a familiar narrative resurfaces in Nigeria’s tech ecosystem:
“We don’t have enough senior technical talent.”

This time, it came from Tosin Eniolorunda, who argued that Nigeria lacks the senior engineers, data scientists, and growth leaders needed to build globally competitive companies and that those we do have are leaving.

It sounds reasonable. It even sounds factual. But it’s not the full truth, and in many ways, it’s dangerously misleading.

The “Talent Shortage” Myth

Nigeria does not have a talent shortage. Oh please!! in a nation of 200+ million people. with some of the fasting growing technology focused startup ecosystems?

Go to any university, private, federal or even a polytechnic and check their faculty of engineering and sciences and you will find some of the most cracked talent at that level on God’s green earth. So rest for God sake!!

A more relevant fact is that Nigeria has a talent mispricing problem. This is facts because there are thousands of highly skilled Nigerian engineers:

• Building systems for global companies remotely
• Leading engineering teams across Europe and North America
• Scaling infrastructure far beyond the “80k users/day” that was mentioned.

These people didn’t disappear. They simply opted out of the local market. Why? Because the same companies complaining about talent scarcity:

• Undervalue senior talent
• Offer compensation that doesn’t match global benchmarks
• Expect world-class output with locally suppressed pay

I am not saying Moniepoint doesn’t “pay well” but that in itself is subjective, I don’t have the median figures for what techies earn but we know minimum wage is N77k, paying someone 3 million naira gross monthly for a mid to senior role is paying “very well” till you take a closer look at the international thresholds of $80k-$150k and even more annually. Your monthly N3million(which by the way 90% of the nation would take) is under $40k per annum. You can’t price talent like it’s 2016 and expect 2026 performance.

“Talent Are Leaving” — But Why?

Blaming Japa is very convenient and very very lazy. Consider for a moment the talent with the actual means to japa, versus the overall number in the talent pool and you would just laugh.

Eniolorunda laments that Nigeria is “losing the small we produce to Japa.” He mentions the 16,000 doctors who have left. What he does not mention is why they are leaving. People do not emigrate because they are ungrateful or unpatriotic. They leave because of collapsed public infrastructure, currency devaluation, insecurity, and the complete absence of a social contract from the Nigerian state.

Meanwhile, companies like Moniepoint that are well-funded, dollar-denominated at the treasury level have benefited enormously from the same macroeconomic conditions that are pushing talent out. The naira collapse that devastates a mid-level engineer’s purchasing power? It makes Moniepoint’s dollar-denominated equity and foreign investment significantly more powerful locally. You cannot profit from the conditions causing brain drain and then lecture the country about the consequences of brain drain.

But talent doesn’t just leave countries. They leave conditions. Senior engineers are not just chasing money, they are choosing:

• Better engineering culture and community
• Stable infrastructure (power, internet, tools)
• Respect for specialization
• Clear career progression

If your best engineers are leaving, the real question isn’t
“Why is talent scarce?”

It should be “Why is staying unattractive?” and what have you done to make it attractive?

• Competitive salaries that match the realities of Nigeria?
• Infrastructure like home internet to enable them work from home
• Structured career progression?

The Experience Paradox (That Companies Created)

The CEO points out a real issue:

Not enough feeder industries → not enough senior talent

That is very true. But here’s what he won’t say. Many Nigerian companies:

• Don’t invest in structured mentorship
• Don’t build junior-to-senior pipelines
• Want to hire finished products, not develop people

So what is the result of this culture? Everyone fights over the same “ready-made” senior engineers. This isn’t a national failure. It’s an organizational strategy failure. I am aware of companies that actually invest in capacity building through their graduate trainee programs and other

His claim that Nigeria lacks “feeder industries” starter companies that produce junior talent who then grow into senior leaders is presented as a passive environmental tragedy. But who builds feeder industries? Large, well-funded companies do. By investing in graduate programmes, paying for certifications, sponsoring bootcamps, creating structured career ladders, and crucially paying people enough that they do not need to leave.

If Moniepoint is growing at 20% year-on-year and cannot find enough senior technical talent locally, the honest question is: what has Moniepoint done, systematically and at scale, to build that senior talent internally over the past decade? Pointing at the talent gap without answering that question is like a farmer lamenting the soil while refusing to water it.

When Big Tech companies in the US faced similar pipeline problems, they built internal universities, funded HBCUs, launched apprenticeships, and lobbied for immigration reform. They did not post on LinkedIn about how the soil was bad.

Global Standard? Then Pay Global Price

You cannot say:

“We want to compete with China and India” …and then:

• Pay 3–5x below global market rates
• Limit stock options or wealth creation
• Overwork teams without world-class systems

Countries like India didn’t magically produce senior talent.

They:

• Built ecosystems
• Attracted global capital
• Paid competitively
• Exported talent and retained enough locally

If Nigerian companies want global outcomes, they must adopt global talent economics.

Nigeria will be great, but not because of this

He ends with “Nigeria will be great. Let’s all do the work together.” It is a fine sentiment. But “doing the work together” has to include companies like Moniepoint publishing their graduate intake numbers, their internal promotion rates, their training budgets, their average engineer tenure, and their naira salary bands for senior technical roles so Nigerians can judge for themselves how much of the “work” is actually being done.

Until then, the post reads less like a call to action and more like a CEO managing the optics of a difficult hiring environment by framing a competitive problem as a national crisis and asking the nation to solve it for him

The Real Constraint Isn’t Talent, duh!! It’s Environment

Let’s be honest:

Even the best Nigerian engineer struggles locally with:

• Power instability
• FX volatility
• Limited access to global tools/services
• Policy uncertainty

These constraints reduce productivity before talent even becomes a factor.

So when companies say: “We don’t have enough quality talent”

What they should be saying is: “We don’t have the environment that allows talent to thrive.”

What a more honest post would say

If Eniolorunda wanted to be genuinely honest since he invokes honesty twice he might have written something like this: We at Moniepoint are competing globally. We struggle to find enough senior technical talent locally. We have contributed to this problem by not investing enough in structured talent development pipelines. We plan to change that with specific, funded commitments. Here is what we are doing. Here is what we are asking other companies to do alongside us. Here is what we need the government to do. Let us hold each other accountable in six months.

That would be self-awareness. What he actually posted is a diagnosis without accountability, a lament without commitment, and a call to action that places the entire burden of the talent crisis on Nigeria’s structural failures while a 20%-growing company with dollar-denominated investment capital stands to the side, nodding solemnly.

What Should Actually Change

If companies like Moniepoint want to fix this, the playbook is clear:

• Pay competitively (not “locally competitive” globally competitive)
• Build internal talent pipelines aggressively
• Create strong engineering cultures, not just delivery pressure
• Offer real ownership (equity, upside)
• Invest in tools and infrastructure that match global standards

Because talent doesn’t scale where it isn’t valued.

Final Thought

The statement “Nigeria lacks senior talent” is not entirely false.

But it’s incomplete. And incomplete truths are often more dangerous than outright lies. Nigeria doesn’t lack talent. It lacks enough systems and sometimes enough honesty to keep it.

I have been privileged to be part of the design, simulation, testing and implementation of IT at an enterprise level over the past couple of years. There have been many ups and downs and of course many lessons.

In my last article, I confessed to needing some clarity on the next step in my career, and like the apple that fell on Isaac Newton’s head, an emergency meeting was called, ZTA kept coming up in this meeting. So for many aspects of our ever-growing infrastructure, we will be implementing ZTA. Of course this is a reaction to recent events in the space.

I have decided to write on what I learned about ZTA and how I would be adopting it on this project.

WHAT IS ZTA?

Zero Trust Architecture (ZTA) is a modern security framework that eliminates implicit trust and enforces continuous verification across users, devices, and systems. It brings value by strengthening network access, hardening SSH, managing certificates, enforcing strict user and privilege controls, and integrating with SIEM and PAM solutions to reduce attack surfaces.

Zero Trust Architecture (ZTA) represents a fundamental shift from traditional perimeter-based security models to a comprehensive security framework that assumes no implicit trust within enterprise networks.

This implementation approach requires continuous verification of every user, device, and transaction, regardless of location or previous authentication status.

Trust is neither binary nor permanent. It can no longer be assumed that internal entities are trustworthy, that they can be directly managed to reduce security risk, or that checking them one time is enough. The zero-trust model of security prompts you to question your assumptions of trust at every access attempt.

Traditional security approaches assume that anything inside the corporate network can be trusted. The reality is that this assumption no longer holds true, thanks to mobility, BYOD (Bring Your Own Device), IoT (Internet of Things), cloud adoption, increased collaboration, and a focus on business resiliency. A zero-trust model considers all resources to be external and continuously verifies trust before granting only the required access.

The transition involves systematic planning across five core pillars; identity, devices, networks, applications, and data with incremental deployment phases that progressively enhance the security posture while maintaining operational efficiency.

The key to comprehensive Zero Trust is extending security throughout the entire network environment with examples such as:

● Employees accessing sensitive applications, both on and off the enterprise network

● Guests and third-parties using the network infrastructure

● Application to application communications

● Communication between control systems

Understanding Zero Trust Fundamentals

Zero Trust Architecture operates on three fundamental principles that distinguish it from traditional security models.

The first principle, “Verify explicitly,” this mandates authentication and authorization based on all available data points, rather than relying on network location or previous access grants.

The second principle, “Use least privilege access,” ensures that users receive only the minimum access necessary for their specific tasks through Just-In-Time and Just-Enough-Access controls.

The third principle, “Assume breach,” requires organizations to minimize the blast radius through network segmentation and continuous verification of encrypted communications.

Traditional security architecture is sometimes referred to as the “castle-and-moat” model. Think of the network as a castle and authorized users “cross the moat” to get inside the network perimeter. Even though this approach was useful to defend against external threats, it failed to address threats that already existed within the network.

This traditional perimeter-based security approach only distrusts factors outside the existing network. Once a threat is able to cross the moat and get inside the network, it has free reign to wreak havoc within the castle that is your system. A zero trust security model is based on identity authentication instead of trusting users based on their position relative to your network.

The NIST SP 800–207 standard defines Zero Trust as “a collection of concepts and ideas designed to reduce uncertainty in enforcing accurate, per-request access decisions in information systems and services in the face of a network viewed as compromised”.

This approach fundamentally differs from perimeter-based security by treating every access request as potentially malicious, requiring continuous validation throughout user sessions.

Protection begins by identifying your protect surface, which is based on data, applications, assets, or services, commonly referenced by the acronym DAAS:

1. Data: Which data do you have to protect?
2. Applications: Which applications have sensitive information?
3. Assets: What are your most sensitive assets?
4. Services: Which services can a bad actor exploit in an attempt to interrupt normal IT operation?

Establishing this protect surface helps you hone in on exactly what needs to be protected. This approach is preferable to trying to guard the attack surface, which constantly increases in size and complexity.

A zero trust policy involves regulating traffic around critical data and components by forming micro perimeters. At the edge of a micro perimeter, a zero trust network employs a segmentation gateway, which monitors the entry of people and data. It applies security measures that are designed to thoroughly vet users and data before to granting access using a Layer 7 firewall and the Kipling method.

A Layer 7 rule could involve inspecting the payload of packets to see if they match known types of traffic. If a packet contains data that doesn’t meet the parameters of the Layer 7 rule, access is blocked. The Kipling method challenges the validity of the entry attempt by asking six questions about the entry and who is trying to get in: Who? What? When? Where? Why? How? If the answer to any of the queries raises a flag, access isn’t granted.

5 Core Pillars of the Zero Trust Security Model

Zero trust is a cybersecurity model that requires continuous verification of all users and devices, regardless of location. Here are five core pillars of the zero trust model that strengthen security:

1. Identity: Zero trust network security authenticates user identities and allows access only to approved users or enterprise resources. Identity and Access Management (IAM) systems, Single Sign-On (SSO), and Multifactor Authentication (MFA) are popular tools that organizations implement for identity verification.

2. Networks: Unlike traditional network segmentation, zero trust supports micro segmentation and separates resources and workloads into smaller, secure zones. This helps organizations contain breaches and prevent lateral movement. Threat actors cannot access resources they are not authorized to use.

3. Devices: All devices, including laptops, mobile phones, servers, IoT devices, printers, and others in the network, must comply with the organization’s zero-trust policies and security controls. Zero trust maintains complete inventories of all authorized endpoint devices and denies network access to unauthorized devices.

4. Applications and workloads: Zero trust doesn’t trust applications and application programming interfaces (APIs). Organizations use ongoing checks to confirm access each time rather than giving permanent access. They also monitor how applications interact to spot any unusual activity.

5. Data: Organizations that implement zero trust categorize their entire data to apply specific access controls and security policies to protect it. Data being transferred, used, or stored is secured with encryption and dynamic authorization. Besides, organizations monitor data activity to detect any signs of a breach or unauthorized access.

Core Implementation Components

Identity and Access Management

Strong authentication mechanisms form the cornerstone of Zero Trust implementation. You must establish multi-factor authentication (MFA), password less authentication, and single sign-on (SSO) systems to reliably verify user and device identities.

The Authentication, Authorization, and Accounting (AAA) framework would provide a structured approach for maintaining network security throughout the access lifecycle.

Conditional Access policies would enhance identity verification by evaluating contextual factors during authentication attempts. Azure Active Directory Conditional Access exemplifies this approach through policy-based access control that considers device compliance, user attributes, network location, and sign-in risk levels. The following configuration example demonstrates conditional access implementation:

text# Azure AD B2C Conditional Access Policy Template
apiVersion: conditionalAccess/v1
kind: ConditionalAccessPolicy
metadata:
  name: "Block-Risky-SignIn"
spec:
  assignments:
    users:
      include: ["All users"]
      exclude: ["Global Administrators"]
    conditions:
      signInRisk:
        riskLevels: ["high", "medium"]
  accessControls:
    grant:
      controls: ["requireMFA"]
      operator: "AND"

This policy configuration requires multi-factor authentication when sign-in risk reaches medium or high levels, effectively blocking potentially compromised authentication attempts.
Fortinet takes conditional access policies to the next level using requirements such as certificates, or security baselines such as OS version, or antivirus status. If the OS version for example of a device requiring access, the IAM would audit the device for its OS version, and if it meets the policy, grants access to the captive portal or login page.

Zero-Trust Network Access

Zero trust network access (ZTNA) is an element of zero trust access that focuses on controlling access to applications. ZTNA extends the principles of ZTA to verify users and devices before every application session to confirm that they meet the organizations policy to access that application. ZTNA supports multi-factor authentication to retain the highest levels of verification.

A key element of the ZTNA concept is the location independence of the user. The application access policy and verification process is the same whether the user is on the network or off the network. Users on the network have no more trust than users that are off the network.

For users off the network, ZTNA includes a secure, encrypted tunnel for connectivity from the user device to the ZTNA application proxy point. The automatic nature of this tunnel makes it easier to use than traditional VPN tunnels. The improved experience for users is leading many organizations to shift to ZTNA to replace VPN access.

The ZTNA application proxy point provides a benefit beyond just the transparent, secure remote access. By putting applications behind a proxy point, ZTNA hides those applications from the Internet. Only those users who have been verified can gain access to those applications.

For this ZTNA, I am think of implementing a certificate based authentication mechanism for verification of any user that wants to access an application, without the right organization-generated certificate, irrespective of having the credentials to access an application , that user will not be able to access that application.

Multi-Factor Authentication

Multi-factor authentication (MFA) verifies the identity of a user by requiring them to provide multiple credentials. With traditional password entry methods, a bad actor only has to figure out a username and password, which often are easy for hackers to acquire. With MFA, users must provide multiple methods of identification.

Multi-factor authentication aids a zero-trust network by increasing the number of user-specific credentials required for access. Using MFA can increase the difficulty for hackers by a factor of two, three, four, or more. An integration of a token provider like Forti Token might be an interesting tool to consider, or Microsoft Authenticator as a source of One time password (OTP).

Endpoint verification

Endpoints need to be verified to make sure each one is being controlled by the right person. Endpoint verification strengthens a zero trust security approach because it requires both the user and the endpoint itself to present credentials to the network. Each endpoint has its own layer of authentication that would necessitate users to prove their credentials before gaining access.

Then, in order for a component or program on the network to allow the endpoint access, it sends a verification out to the endpoint. The user then responds on the device. The data sent from the endpoint is used to check its validity, and a successful receipt and transmission process earns the device the status of “trustworthy.”

Unified endpoint management (UEM) allows administrators to centralize how they manage IT infrastructures by giving them a single set of tools they can use to verify multiple endpoints. Endpoint detection and response (EDR) verifies the safety and security of the endpoint. EDR works like a multifaceted antivirus. It scans the endpoint, identifies threats, and then takes steps to protect the endpoint, isolate it from the network if necessary and by extension, the rest of the network.

Microsegmentation

Microsegmentation involves creating zones within the network to isolate and secure elements of the network that could contain sensitive information or provide access to malicious actors. A zero trust security approach benefits from microsegmentation because once the secured area has been microsegmented, it’s protected from threats. The firewall or filter that forms a barrier around the zone can also block threats from exiting the zone, which protects the rest of the network.

Least-Privilege Access

Least-privilege access refers to allowing users and devices to access only those resources that are essential to performing their duties. A zero trust security setup benefits from least-privilege access because it limits the number of points of entry to sensitive data or infrastructure. Least-privilege access may also save time and resources because fewer MFA measures have to be employed, which limits the volume of identification credentials that have to be granted and managed.

The Active Directory configuration specifically Role Based Access Control (RBAC) can help with the implementation of least privilege by ensuring roles have only the necessary access to carry out their various responsibilities.

My High Level Implementation Plan

Strategic Planning and Assessment Phase

A successful Zero Trust Architecture implementation should begin with a comprehensive organizational assessment and the formation of a cross-functional team. This implementation will be cross-cutting across business units such as the networking, cloud, software and cybersecurity and therefore each stakeholder must be ably represented.

Creation of Implementation team

I plan to create a team comprising management cadre, network unit, cybersecurity unit, infrastructure architects, engineers and software developers to identify our critical assets and map attack surfaces.

This approach will ensure an alignment between business objectives and security requirements, and hopefully facilitate a smooth implementation across our organization’s various business units. It will also promote collaboration and ensure inclusivity.

This assessment process will involve some critical steps for effective implementation.

Step 1 We will identify all users, devices, and applications accessing the network, including their roles and access requirements. Our Access control list(ACL) would provide lots of value here.

Step 2 We will break the implementation into phases, prioritizing the most vulnerable business areas, and critical assets will be considered and given priority. This phased approach is aimed at preventing overwhelming the technical teams while ensuring systematic coverage of the enterprise infrastructure. A high level work plan would be an outcome of this step.

Step 3 We will focus on identifying technological gaps in current infrastructure and investing in necessary security tools. We will need to look at our authentication systems, privileged access management solutions, and our monitoring capabilities. This technological foundation supports subsequent implementation phases while addressing immediate security vulnerabilities.

Some High Level Technical Implementations I’ve Considered

1. Network Access

• Replace VPNs with software-defined perimeters.
• Segment workloads to prevent lateral movement.
• Deploy identity-aware rules on NGFW.

2. SSH Hardening

• Rotate SSH keys regularly and store them in Privileged Access Management (PAM) vaults.
• Apply just-in-time access for administrators.

3. Certificates & PKI

• Use short-lived certificates for devices and services.
• Automate certificate issuance and renewal .

4. Identity & User Management

• Deploy multi-factor authentication (MFA) across all accounts.
• Automate identity lifecycle management (onboarding, offboarding, privilege revocation).

5. Privileged Access Management (PAM)

• Store admin credentials in vaults with audit trails.
• Enforce session recording for privileged activities.
• Apply just-in-time elevation instead of permanent admin rights.

Merits

Implementing zero trust architecture yields numerous advantages that significantly enhance an organization’s security posture and foster a more agile and resilient IT infrastructure. The inherent flexibility of zero trust architecture enables organizations to readily adapt to evolving business needs and embrace modern work models and cloud technologies with confidence. A comprehensive zero trust architecture diagram illustrates these advantages within the context of an organization’s specific network topology.

User and Device Security User and Device Security provides solutions that establish trust in users and devices through authentication and continuous monitoring of each access attempt, with custom security policies that protect every application. With a zero-trust approach to securing users and devices, you can help prevent or mitigate against several different types of attacks that target users and devices in this new perimeter-less world:

The ideal end state of your zero trust for user and device security would allow your enterprise to answer the following:

● Are my users really who they say they are? Verify the identity of every user, regardless of type (contractors, vendors, third-party providers, partners, remote users, employees, temporary workers, etc.)

● What devices are connecting to my applications and data Get visibility into every type of device, both managed or unmanaged (mobile, laptops, and desktops; company-issued, -owned, or -managed; user-owned)

● Who or what is allowed to access my applications and data? By enforcing adaptive access policies, you can limit access to enterprise applications and data based on user role, type of device, security health of user devices, user group, application type, and much more

● How can I enable remote, frictionless access for all users? With a remote-access proxy, you can enable access to multi-cloud environments, web applications, servers, VPNs, and more for employees, remote workers, and contractors. With Single Sign-On (SSO), you can allow users to securely access their cloud and on-premises applications seamlessly by logging in just once.

In an enterprise architecture, the network may span multiple domains, locations, or sites such as main campuses and remote branches, each with multiple devices, services, and policies. A Zero Trust solution should demand an end-to-end architecture that ensures consistency in terms of connectivity, segmentation, and policy across the full spectrum of the network.

Zero Trust for the network and application security enables network administrators to:

● Know who is on the network. To truly secure the network, you need to know what is connecting to it. For managed devices, such as laptops and smartphones, mobile device management (MDM) can be used to determine what the connecting device is what it says it is. For unmanaged devices, such as BYOD or IoT devices, network-based machine learning can be used to identity attributes for categorization, while sensitive workloads can be limited to managed devices controlled by the enterprise

● Define what endpoints can access. Segmentation and access policies should be easily defined for individual devices as well as groups of similar devices. These policies should be defined with least privilege access to help ensure that the devices have only the minimal level of access to minimize the potential for lateral movement of threats

● Provide always-on analysis and enforcement. Security threats are always evolving, so a continuous loop of analysis and enforcement must be administered to stay atop intrusions and vulnerabilities. It is important to understand traffic norms and identity the out-of-policy traffic, enabling device isolation in the case of an event

Application and Data Security

Application and Data Security secures connections for all APIs, microservices, and containers that access applications, whether in the cloud, data center, or other virtualized environment.

Enterprise networks are increasingly becoming more complex as applications move to multi-cloud and leverage containers and microservices, effectively creating new security, reporting, and compliance challenges. With a zero-trust approach to securing applications and data, you can help prevent or mitigate against several different types of attacks that target applications:

The need for comprehensive visibility of all network traffic down to the individual workload level for effective security policy management and enforcement has never been more important than now. The ideal end state of your zero trust for the workloads solution would allow your enterprise to answer the following:

● Do I have complete visibility of application communication? Achieving comprehensive zero trust and true end-to-end visibility across on-premises and multi-cloud environments requires robust network-based detection and response. It is critical to understand who and what are on the network before any segmentation policies can be applied

● Can I control workloads moving laterally throughout the network? When you have visibility across how the digital business operates, you can create smart segmentation policies to control access to critical resources. This ability is very important to prevent threats from spreading and creating a significant impact.

● Do I understand the posture of my applications and are they compliant with industry best practices? Organizations that have moved resources and workloads to public cloud environments like AWS, Azure, and Google Cloud Platform face a multitude of new security, policy, and compliance-related challenges. Developing robust cloud security posture management (CSPM) capabilities such as monitoring risk exposure levels related to configuration, network segmentation, user, and system events helps guarantee sound policy management and protect against data leakage

Challenges of the Coming Implementation

With any implementation comes challenges (duh), and as the title states, I was thrown into this, so there will definitely be a number of them, but let’s look at the common challenges anybody would face with such an implementation.

• Complexity: Integrating IAM, SIEM, and PAM requires orchestration and lots of technical know-how. Sometimes the documentation to carry this out is not available, or more they simply do not support such integration.
• Legacy Systems: Older infrastructure may not support Zero Trust controls. In every enterprise you will find legacy system, there’s the saying “if it ain’t broke!” Many of these systems are usually fully functional but in the rat life of life, are ignored for many reasons.
• User Resistance: MFA and strict access policies may face pushback. Human beings are a source of much of my headache, and I already anticipate the feedback I will get from them. Feedback is great, and I strive to create an environment where feedback is freely and honestly given. When you’ve worked with people, you will know that convenience is way more important to them than security.
• Cost: Enterprise-grade SIEM and IAM solutions can be expensive. Bruh like very expensive godammit (forgive my language for I have seen costs). Once again, this should not be an excuse to not acquire them, the ROI is often worth it, avoiding loss of face, regulatory and legal repercussions and loss of data usually costs more in the short and long term so……..

Final Thougts

This article has gone long enough to be honest, but as you know, I use my writing to also arrange my thoughts, this writing has brought me much more clarity.

This whole ZTA thing has been in the works for ages, but it took recent breaches to fast forward it so, I thank the threat actors (Please leave us alone)

I hope you have found value in today’s article, consider subscribing, clapping and following me on my socials. If you have any questions, I am only a DM away.

• LinkedIn: https://www.linkedin.com/in/m49d4ch3lly
• Twitter: https://twitter.com/m9D4ch3lly
• GitHub: https://github.com/UFarouk10
• Gmail: Umarfarouk037@gmail.com

Cybersecurity awareness is an active force within every company’s culture. It serves as the quiet sentinel guarding each email opened, every password chosen, and every system login attempted.

If you have ever doubted the reality of the cyber threats, you need not look further than the past 4–6 weeks. Major financial institutions including FCMB , sterling bank, even the Corporate Affairs commission(CAC) was breached. Cyber threats are not theoretical affairs or case studies but our daily realities.

The risk is universal, from ransomware attacks on multinational corporations to phishing scams targeting small business owners. Yet despite billions spent annually on cybersecurity tools, most breaches still happen because of one thing: human error. In Nigeria specifically, we are resistant to change and very stubborn

Proofpoint’s 2024 Voice of the CISO report found that three in four (74%) chief information security officers (CISOs) said human error was their top cybersecurity risk. This reveals significant growth from last year’s 60% of CISOs expressing this sentiment. The study also found a key gap between CISOs and the boardroom. Board members were less likely (63%) to point to human error than CISOs, which shows that CISOs should focus on educating leadership as well as employees.

Several of the top causes for data loss events in the survey were related directly to employees. The top response (42%) was negligent insider/employee carelessness, such as an employee misusing data. Other reasons included a malicious or criminal insider (36%), stolen employee credentials (33%) and lost or stolen devices (28%).

The IBM 2024 threat index supports this finding, indicating that 30% of attacks start with phishing. However, phishing attacks are down from 2022, both in volume and as the initial attack vector. The report points to the continued adoption and reevaluation of phishing mitigation techniques and strategies as one of the reasons for the reduction.

Organizations must take a proactive approach to cybersecurity, which includes providing training so employees can learn safe practices while also setting up processes that reduce risk.

Building a culture of cybersecurity awareness is, therefore, not a technical initiative; it’s a human one.

What is Cybersecurity Awareness?

Most organizations confuse awareness with training. They think a once-a-year online quiz is enough. It’s not.

Proper cybersecurity awareness is a continuous cultural process: a shared mindset where every individual feels responsible for protecting the company’s digital assets and understands their role in promoting security.

It involves education, communication, behavioral reinforcement, and leadership alignment. It’s less about teaching people what to do and more about helping them understand why it matters.

When employees see cybersecurity as part of their job, not an IT problem; everything changes.

The Human Shield: Why Awareness Must Complement Technology

You can have a suit of technical security controls ala firewalls, endpoint protection, and encryption in place. But if an employee clicks a malicious link disguised as a legitimate communication, all that investment collapses in a second (note: there are technical security controls that are put in place to block phishing emails and malicious links).

This is why awareness must sit alongside technology as an equal pillar of any security strategy. Security awareness training equips employees to recognize red flags — suspicious emails, unusual login requests, unsolicited USB drives. It cultivates a culture where security is everyone’s responsibility, not just the IT department’s concern. When staff understand why certain behaviors are risky, they are far more likely to act with caution.

But awareness is not a one-time checkbox exercise. Threat actors evolve continuously, and so must human knowledge. Regular simulations, phishing drills, and updated training ensure that vigilance doesn’t decay over time. The goal is to build instinct in a workforce that pauses before clicking, questions before sharing, and reports before ignoring.

Technology and awareness are not competing investments; they are complementary layers of defense. Firewalls stop known threats at the gate. Informed humans stop unknown ones before they even arrive. Together, they form the most resilient security posture an organization can build — one where the human, once the weakest link, becomes the strongest shield.

Why Teams Struggle to Build a Cybersecurity Culture

Many well-meaning organizations fail to make cybersecurity awareness work. I have experienced this in multiples organizations I worked with or consulted for.

They roll out compliance training that’s dull, technical, and detached from employees’ daily work. They punish mistakes instead of rewarding vigilance. They treat security as a project, not a philosophy.

The result? Employees tune out. Awareness fades. Vulnerabilities grow.

A culture of cybersecurity awareness thrives only when it is consistent, inclusive, and psychologically safe. People must believe they can report mistakes without fear and that their actions genuinely make a difference.

The Stakes Are Higher Than Ever

Cyberattacks have become more creative, more targeted, and more damaging.

• Statista reveals that in 2023, roughly 7 in 10 global cyberattacks were ransomware, with over 317 million attempts recorded.
• Another report by Statista states that the total amount of money received by ransomware actors was $1.1 billion in 2023, an increase of 140% from $457 million in the prior year.
• That’s not all. The FBI’s 2024 IC3 Report revealed that in 2024, the IC3 received 3,156 complaints (up 11.7% from the previous year) identified as ransomware attacks with adjusted losses of over $12.4 million. This reflects the financial impact that ransomware incidents continue to inflict on businesses.
• Phishing remains the number one attack vector, responsible for over 36% of all breaches.

But beyond financial loss, a breach affects the trust with customers, partners, and employees alike. In the era of remote work and hybrid teams, trust is valuable currency.

That’s why cybersecurity awareness is no longer optional. It’s essential.

Building a Cybersecurity Awareness Culture: Step-by-Step Guide

It would be amiss of me to preach cybersecurity awareness culture without sharing what has worked for me (tbh this is at a large school and medium scale enterprise level, with an enterprise I am still finding my footing). I will be sharing a step by step guide in the next section

Step 1: Leadership Commitment sets the tone

No awareness initiative can survive without leadership buy-in. Employees look to leaders for cues on what matters.

When executives talk openly about cybersecurity in meetings, participate in training, and share stories of vigilance, it sends a powerful message: security is everyone’s business.

Leaders must model the behaviors they want others to adopt , using multifactor authentication, reporting suspicious emails, or following clean desk policies.

According to Gartner, companies with visible leadership participation in cybersecurity programs see up to 50% higher employee engagement rates in awareness activities.

Culture cascades from the top down.

Step 2: Make Awareness Personal and Relevant

People engage when they see relevance. Making cybersecurity personal brings home the fact that it is not just the corporation getting hit, but real people sited around them, friends, families and acquaintances alike.

Show employees how cyber threats can affect not just the organization but also their personal lives: stolen credit card details, identity theft, or compromised family data.

Using real-world examples drives home the point:

• A phishing email pretending to be from HR.
• A text scam targeting delivery confirmations.
• A fake LinkedIn message asking for credentials.

I usually begin the engagement by asking the people to share an experience of when they were scammed. This serves as a few things:

• And ice breaker
• Opening the space for the people to be vulnerable
• Showcasing the real lives that have been affected

There are people in the set that have never experienced any successful cyber attack, at the end if this exercise, they are able to visualize the threat, and internalize the lesson.

Cybersecurity awareness campaigns that link security habits to personal protection create deeper, longer-lasting behavior change.

Step 3: Train Continuously, Not Occasionally

Cybersecurity awareness fades quickly. Studies show that employees forget 70% of training content within a week if it’s not reinforced.

The solution? Continuous learning.

Microlearning (short, focused modules of 5–10 minutes) keeps cybersecurity top of mind without disrupting workflow. Combine it with engaging formats like quizzes, interactive videos, and gamified challenges.

For example, I used the platform Knowe4 for continuous learning, and they have gamified learning that promotes fun and reinforces memory retention. They also have video series that employees found very engaging, especially the “insider threat” a show on social engineering.

Step 4: Simulate Real Threats

Practice makes perfect, and cybersecurity is no exception.

Running simulated phishing campaigns regularly to test awareness in realistic conditions is a must. These exercises identify vulnerable areas and offer instant, personalized feedback.

However, avoid shaming employees who fall for simulated attacks. Instead, turn those moments into teachable opportunities. The goal is growth, not guilt.

Data from KnowBe4, shows that organizations running monthly phishing simulations improve resilience by up to 75% within 12 months.

Simulation turns theory into actionable daily practices.

Step 5: Communicate Creatively and Frequently

The best awareness campaigns use creativity to stay memorable.

Avoid dense policy documents. Communicate them frequently and opening. Shared them physically and digitally if you have to. Use infographics, short videos, emails, memos or memes that grab attention. Make cybersecurity visible in frequently visited areas, dashboards, and chat channels.

In my experience Knowbe4 is my platform to go. They have a suit of short videos, including infographics that can printed and pasted on walls or simply emailed to everyone.

Your communication doesn’t need to be fancy; it needs to be human. A little humor and design go a long way toward engagement.

Step 6: Create A Safe Channel for Reporting

A strong cybersecurity culture depends on open communication.

Employees should never fear reporting suspicious activity or admitting to mistakes. Early reporting can stop a small incident from becoming a disaster.

Establishing a simple, confidential reporting process like a Slack channel, a helpdesk line, or a form. Reward quick reporting publicly.

Once again, we are building a culture here, and I am sure open and non-judgmental communication are very attractive for a healthy working environment

As Google’s former security engineer Heather Adkins once said, “Security fails when people are afraid to tell you the truth.

Step 7: Recognize and Reward Positive Behavior

Behavioral science shows that recognition shapes habits. When people are praised for doing something right, they repeat it.

Celebrate those who complete cybersecurity challenges, report phishing attempts, or help others stay secure.

One mid-sized U.S. law firm introduced “Cyber Hero Fridays,” where employees who demonstrated exemplary security behavior were highlighted in company newsletters. Within six months, security incident reporting rose by 62%.

Positive reinforcement turns cybersecurity from a rulebook into a shared value.

Step 8: Measure What Matters

Continuous improvement and harmonization of data provide the foundation of improving any cybersecurity program. You can’t improve what you don’t measure.

I advise you track data such as:

• Phishing test click rates
• Reported incidents
• Training completion rates
• Employee feedback around security culture

Visualize results in dashboards and share progress across to management. Seeing measurable improvement boosts morale and accountability.

According to Forrester Research, organizations that measure behavioral indicators, not just compliance, experience 37% fewer security incidents over time.

Data drives harmonization and optimization.

Step 9: Align Security and Business Goals

A common notion is that cybersecurity is a barrier to productivity and innovation.

In truth, cybersecurity enables business continuity, customer trust, and innovation. Awareness programs should communicate that secure behavior isn’t restrictive, it’s empowering.

When employees understand that cybersecurity protects their work, their clients, and their company’s reputation, resistance would begin to turn into advocacy.

Always frame cybersecurity awareness programs not as a cost, but as a strategic investment and enabler of business.

Step 10: Keep Evolving with the Threat Landscape

Cyber threats evolve constantly and so should your awareness program.

Regularly update your training materials and campaigns to reflect emerging trends: AI-powered scams, deepfake impersonations, or QR-code phishing (“quishing”).

Incorporate stories from recent global incidents to stay relevant. For example, after the 2024 MGM Resorts breach, several hospitality firms updated their training to focus on social engineering awareness.

Cybersecurity culture is never “done.” It’s a continuous evolution of habits, communication, and trust.

Common Mistakes That Undermine Cybersecurity Awareness Efforts

Cybersecurity awareness programs fail less because of lack of effort and more because of subtle, repeated mistakes. If you’re building or auditing one, these are the patterns that quietly undermine effectiveness:

Overwhelming Employees with Technical Jargon

Avoid overcomplicated language. Translate “enable multifactor authentication” into “add a second lock to your account.” Simple, relatable communication always wins. Translate “data breach” into “exposed or stolen credentials or passwords”. Translate “Patch” into “fixes for security problems in your apps or system”.

Treating Training as a One-Time Event

Security threats evolve daily; awareness should too. Reinforce key topics quarterly, not annually, to keep employees alert and informed.

Failing to Align Security Goals with Business Objectives

When employees see cybersecurity as a blocker, they’ll find ways around it. Align awareness programs with productivity and business outcomes to ensure buy-in.

Building Cybersecurity Awareness Across Hybrid and Remote Teams

Hybrid and remote work have permanently changed the working landscape. With employees using personal devices, home Wi-Fi, and a mix of collaboration tools, the traditional network perimeter has disappeared. Each connection now represents a new point of potential risk.

A 2024 Gartner study found that 68% of breaches involving remote workers stemmed from insecure home networks or shared devices. That statistic alone underscores why cybersecurity awareness must extend beyond the office walls.

The most effective way to maintain vigilance is through structured, ongoing engagement.

Brief virtual sessions, monthly phishing drills, and quick “cyber check-ins” can help remote employees stay alert to new threats. Encouraging managers to start meetings with a “Cyber Tip of the Week” keeps awareness consistent and approachable.

Beyond training, ensure remote teams have secure tools: VPNs, password managers, and endpoint protection, and understand why these safeguards matter. Pairing practical education with the right resources builds both competence and confidence.

Finally, make security personal. Remind remote employees that protecting company data also protects their own digital lives. When cybersecurity awareness becomes part of everyday communication, it transforms from a policy into a shared habit.

Enforce policy

Awareness without enforcement becomes optional advice. Enforcement without awareness becomes frustration.

You need both working together.

Reinforce policy with real consequences

If users violate policies and nothing happens, awareness loses credibility.

Examples:

• Repeated phishing failures → mandatory retraining
• Policy violations → restricted access or escalation

Consistency is more important than harshness.

Conclusion

As cybersecurity strategist Bruce Schneier famously said, “Security is not a product, but a process.” That process must live inside your company culture.

Cybersecurity awareness isn’t built in a day. It’s built every time an employee pauses before clicking, verifies a sender, or reports a suspicious link.

It’s built through conversation, curiosity, and consistency.

The organizations that thrive in the digital age are those that understand that technology protects systems, but awareness protects everything else.

Building a culture of cybersecurity awareness is not just about reducing risk. It’s about cultivating trust, confidence, and resilience in every corner of your organization.

When awareness becomes habit, cybersecurity becomes culture, and culture is the best defense of all.

Cybersecurity is one of in-demand fields right now and also one of the easiest field experience the “burn out”. On paper, it looks rewarding: high demand, good pay, meaningful work.

There’s always another vulnerability, another audit, another incident, another deadline. Sometimes, it feels like no matter how much you do, it’s never enough. It takes time, energy, and mental resources to be in this field. In other words, pressure choke. I have experienced that pressure firsthand.

Stepping away from 24/7 cyber has been the path to clarity and recovering from burnout. Here are some hobbies I’ve been doing to balance work and play.

For GRC professionals especially, burnout can hit differently. You’re balancing compliance expectations, business realities, and technical risks often acting as the bridge between worlds that don’t always understand each other.

You’re expected to:

• Explain time and again risk (to whoever it may be)
• Push back on insecure practices (therefore making people dislike you)
• Keep up with news, trends, frameworks and regulations
• Prepare for periodic or ad-hoc audits

It adds up. To be honest I might have hit a wall myself. I’m a few years in and ready for the next phase. I have a few ideas but nothing fleshed out. I’m not sure if that’s normal , so I am currently seeking some clarity.

My Turning Point

At some point, I realized something important: the burnout wasn’t just about the workload, it was about how I was responding to it.

I was trying to:

• Be available all the time
• Solve everything immediately
• Prove my value in every conversation

That mindset is unsustainable in cybersecurity. So I reflected and changed my approach.

What Burnout in Cybersecurity Really Looks Like

Burnout in this field doesn’t always show up as dramatic exhaustion. Sometimes it’s subtle:

• You stop feeling excited about solving problems you used to enjoy
• Alerts, audits, and meetings start to feel overwhelming instead of routine
• You feel like you’re constantly behind, even when you’re doing your best

When I feel overwhelmed, I play Strategy Games; At least that’s what I call them.

Football Manager

Football Manager(FM) is a very popular football simulation video game series where you take on the role of a football club manager instead of playing on the pitch.

You’re the boss of a football team, with the objective to build a dream squad, craft the ultimate game plan, tactics and feel the thrill of winning football’s biggest trophies.

Football Manager 26 distills the drama and deep immersion in the would of a would be football manager, unlike more mainstream games like EAFC(FIFA) and EFootball (PES), played from the perspective of the on-field football players and not much more.

Instead of controlling players directly, you manage everything behind the scenes:

• Team selection & tactics : you get to choose formations, style of play, and starting lineup

• Transfers — you have the ability to decide to buy and sell players, and like real-life clubs it might be the role of the Director of Football.

• Training & development —you can coach attributes and specialized skills to improve players over time
• Match decisions —the ability to make tactical changes during games in order to win or salvage a draw is one of my favourite parts of the game.
• Club management — deal with finances, staff, media, and board expectations

Why I love it

There’s a lot of reasons to love the game to be honest, it is a game you can play in the background while attending to other tasks.

• Extremely realistic database; there are literally thousands of real players and clubs. Apparently real clubs leverage on this large database in their scouting(Brighton have admitted to this, I wouldn’t be shocked if Chelsea do the same)
• Deep strategy (I spend hours perfecting tactics and sharing with the community)
• Feels like being a real-life manager like Pep Guardiola or José Mourinho :)

Simple way to think about it

If FIFA is about playing football, Football Manager is about running a football club.

Total War Series

Total War is a series of strategy games developed by British developer Creative Assembly for personal computers. They combine turn-based strategy and resource management with real-time tactical control of battles. Rather uniquely for real-time strategy games, flanking manoeuvres and formations factor heavily into gameplay. The first of the series, Shogun: Total War, was released in June 2000. The most recent major game released was Total War: Pharaoh on 11 October 2023.

I love this game firstly because of the real historical implications of the game. Historical battles from the Union Jack’s participation in the Napoleon wars. The Britannia campaign, a more medieval war focusing on the expansion of the Britannia empire and dealing with invaders from Europe.

This game demands much more focus than FM, but is still another one I can zone out to and focus on other tasks as it plays in the background

Photography

Photography has become a love of mine. I only use my phone by the way, maybe one day it because something more.

It’s surprisingly technical when you deep dive. Figuring out the shot you’re looking for, find the perfect angle and focus placement, waiting for the best lighting, balancing the aperture, shutter, and ISO, throwing the RAW into Lightroom and tune all the bells and whistles you’d like to form the perfect picture.

Sometimes a different perspective is all we need. Cognitive psychology has shown using our creative brain and analytical brain together is where our natural abilities really shine. So let’s creative! If these ideas don’t spark your interest, don’t be afraid! There’s so many hobbies out there.

Cyber skills don’t just apply to cyber — they’re fully transferrable! You want to find some that you can relax and have fun! Hobbies are crucial to mental health and work-life balance. Don’t skip in identifying yours!

Other ways I Handle Burnout

I Accepted That Security Is Never “Done”

This was the first big shift. There will always be:

• Another vulnerability
• Another framework requirement
• Another improvement to make

Once I accepted that security is a continuous journey, not a finish line. I decided to stop putting unrealistic pressure on myself to “complete” everything. Now I focus on prioritization over perfection.

I Focus on Impact, Not Activity

Early on, I equated being busy with being effective.

Now I ask:

• What actually reduces risk?
• What matters most to the business?

Instead of doing 20 low-impact tasks, I focus on the 2–3 things that truly move the needle.

This reduces stress and increases clarity.

I Set Clear Boundaries

Cybersecurity can easily take over your life if you let it.

I’ve learned to:

• Log off when the workday ends (unless it’s truly critical)
• Avoid checking emails late at night
• Protect my weekends when possible

The truth is: you can’t think clearly about anything, especially risk when your mind is exhausted.

I Communicate, Not Carry Everything Alone

One major cause of burnout is silent pressure.

Now, I:

• Escalate risks clearly instead of internalizing them
• Communicate realistic timelines
• Push back when expectations are not aligned with capacity

Good GRC isn’t about saying “yes” to everything — it’s about being honest about risk and limitations.

I Invest in Learning — But Intentionally

Cybersecurity evolves fast, and the pressure to “keep up” is real.

Instead of trying to learn everything, I:

• Focus on areas aligned with my goals
• Learn in structured ways (not random overwhelm)
• Take breaks from learning when I feel mentally drained

Growth should feel challenging — not suffocating.

I Build Outside Cybersecurity

This one is underrated.

Your identity cannot be only cybersecurity.

For me, that means:

• Creating content
• Thinking about financial growth and investments
• Exploring ideas outside security

It helps me detach and come back sharper.

Final Thought

Burnout doesn’t mean you’re weak. It usually means you’ve been strong for too long without the right systems in place.

Cybersecurity is a long game. If you don’t learn how to manage your energy, the field will consume it.

Now, I approach my work differently:

• I think long-term
• I prioritize what matters
• I protect my mental space
• I play games

And most importantly, I remind myself: You don’t have to solve everything today to be effective in cybersecurity.

If you’re feeling burnt out in cybersecurity, you’re not alone. Almost everyone in this field goes through it at some point.

The goal isn’t to avoid pressure, it’s to build a sustainable way to handle it.

Because in this industry, endurance is just as important as skill.

Use Case: BusyBody Limited: Inside a Modern Enterprise

Imagine a company like BusyBody Limited — a large-scale enterprise with over 20,000 employees operating across multiple lines of business. Over the years, it has built deeply customized tooling to support its on-premise data centers, while gradually adopting a hybrid cloud model to scale and modernize its operations.

This isn’t a startup with endless venture capital. While teams are well-funded, budgets are still scrutinized, and every investment must justify its value. As a publicly traded organization generating over $10 billion in annual revenue, BusyBody Limited operates under constant pressure to balance growth, efficiency, and regulatory expectations.

To understand how such an organization functions, it’s important to look at how its core disciplines — security, compliance, and engineering — are structured.

Security: Decentralized but Specialized

Security in BusyBody Limited is not a single monolithic function — it’s a distributed ecosystem.

Rather than relying solely on a central security team, the organization embeds security capabilities within individual business units. Each unit operates with a degree of autonomy, maintaining its own capabilities across:

• Threat intelligence
• Incident detection and response
• Security architecture
• Compliance alignment
• Security reviews and assurance

This model allows security to scale with the business, but it also introduces challenges in consistency, visibility, and coordination across teams.

Compliance: Mature, Experienced, and Always Under Pressure

With its size and history, BusyBody Limited has a well-established compliance function that has undergone numerous regulatory and external audits.

The compliance organization is typically segmented into specialized teams, such as:

• Internal Controls: ensuring policies and controls are properly designed and implemented
• Audit Management : interfacing with external auditors and managing audit cycles
• Customer Trust & Assurance: responding to customer security questionnaires and due diligence requests

These teams are staffed with professionals who are highly experienced in navigating complex regulatory environments. However, they constantly face pressure — from evolving regulations, demanding auditors, and increasing customer expectations.

Engineering: Diverse, Autonomous, and Complex

Engineering at BusyBody Limited is far from uniform. It spans multiple functions, including:

• Product engineering
• DevOps and infrastructure
• Technical support
• Internal tooling development

Each team operates based on its own context — technology stack, business priorities, and operational model. As a result, there is significant variation in how key processes are handled, such as:

• Access management
• Change management
• Configuration deployment
• Vulnerability patching
• Privacy prioritization

While this autonomy enables speed and innovation, it also creates fragmentation, making it difficult to enforce consistent security and compliance practices across the organization.

The Reality: Constant Trade-offs

Despite having dedicated teams across security, compliance, audit, and legal, BusyBody Limited is in a constant balancing act. There is never enough budget, headcount, or cross-functional alignment to meet every demand.

This tension — between scale and control, autonomy and standardization, speed and assurance — is exactly where modern GRC engineering must step in.

Challenges faced by BusyBody Limited

Constantly evolving privacy/security compliance requirements

a) Keeping up with the dynamic nature of privacy and security compliance is a significant challenge. New regulations and updates to existing ones, require constant monitoring and adaptation.

b) Compliance gap analysis: Conducting regular assessments to identify any gaps in compliance and ensuring that existing systems and processes align with the latest requirements is a time-consuming but essential task.

c) Resource-intensive updates: Implementing changes to meet updated compliance standards often requires significant resources, both in terms of time and personnel, adding strain to the overall operational capacity of the organization.

Blindsided by engineering teams and their velocity

a) Communication barriers: There may be a lack of effective communication channels between the compliance team and engineering teams, leading to a lack of awareness about impending compliance requirements.

b) Integration challenges: Aligning compliance measures with the fast-paced development cycles of engineering teams can be challenging, with potential conflicts arising between the need for quick releases and the thoroughness required for compliance.

Culture and Buy-in push back

a) Integrating compliance tasks into the sprint cycles of engineering teams can be met with resistance as it may disrupt their established workflows and increase workload.

b) Perception of hindrance: Engineers may view compliance requirements as additional obstacles to their primary development goals, resulting in a negative attitude towards compliance teams.

c) Balancing act: Striking a balance between meeting compliance needs and maintaining the efficiency of engineering processes is an ongoing challenge, requiring constant negotiation and collaboration.

Interest by leadership due to regulatory fines

a) Reactive approach: The sudden interest in compliance due to regulatory fines may lead to a more reactive than proactive approach, potentially resulting in rushed implementations and overlooked details.

b) Shifting priorities: Leadership may prioritize compliance solely as a response to external pressure, without fully understanding the long-term benefits of a robust compliance strategy beyond avoiding penalties.

c) Education gap: There may be a need to educate leadership about the broader advantages of maintaining a strong compliance posture, such as building trust with customers, protecting the brand reputation, and ensuring long-term sustainability.

Audit Engine: Supporting architecture

Before we describe the audit engine, we need to have 2 things

• List of all controls
• List of all the possible applications, dependencies and tools that you need to pull data from during an audit (they will be used to develop integrations)

Lets go through each component

Controls Home (datastore) : This is a source of truth for all your controls. This could be a database with rows containing details of your controls. If you have a CCF, it becomes a lot easier to create this database. Below is an example schema

CREATE TABLE controls_home (
    control_id SERIAL PRIMARY KEY,
    control_name VARCHAR(255) NOT NULL,
    control_area TEXT,
    frameworks VARCHAR(100),
    compliance_owner VARCHAR(100) NOT NULL
);

ChecksDB : This service contains all the information required for the team and the downstream services to perform checks. It provides a web interface for the compliance team to perform CRUD operations on the controls checks. There can be multiple checks for each control since there may be more than 1 check required to meet the objectives of the control. ChecksDB stores a history of all checks performed, maintains an audit log of the audits. Below is an example schema:

CREATE TABLE checks (
    check_id SERIAL PRIMARY KEY,
    control_id INT REFERENCES controls_home(control_id) ON DELETE CASCADE,
    check_function TEXT NOT NULL,
    frequency VARCHAR(50) NOT NULL
);

ScopeDB: This services contains details about the scope for an ongoing audit. During an audit when an auditor picks some samples this is where we can store them. The compliance team can interact with this service to add/edit/delete the sampling information for the audit. Below is an example schema:

CREATE TABLE ScopeDB (
    audit_id SERIAL PRIMARY KEY,
    audit_name VARCHAR(255) NOT NULL,
    audit_start_date DATE NOT NULL,
    audit_end_date DATE NOT NULL,
    owner_name VARCHAR(100) NOT NULL,
    sampling_details JSONB,
    CONSTRAINT valid_dates CHECK (audit_start_date <= audit_end_date)
);

Audit Engine

The heart of the tooling, acting as the central hub that seamlessly connects and orchestrates various components. Its versatility is highlighted by its operation in two distinct modes: Continuous Compliance and Audit Period.

Continuous Compliance mode: In Continuous Compliance mode, the Audit Engine demonstrates its capability to maintain an ongoing assessment of the organization’s adherence to predefined controls. It accomplishes this by first reading checks from ChecksDB, ensuring that the latest compliance criteria are considered. The engine then efficiently pulls relevant data from integrations, incorporating information from various sources to provide a comprehensive view of the compliance landscape.

Its scalability is a key feature, adapting dynamically to the breadth and depth of controls in place. By creating insightful data-points, the Audit Engine delivers meaningful information to the compliance team, avoiding unnecessary noise and facilitating a focused approach to continuous compliance monitoring.

Audit Period Mode: During an audit period, the Audit Engine shifts its focus to the specific task of auditing samples identified in ScopeDB. It retrieves sampling data from ScopeDB, which serves as a repository for details about the depth of an ongoing audit. In conjunction with data from integrations, the engine meticulously examines each sample, utilizing validation functions represented in the check_function.

This process involves a thorough validation of the collected data against predefined criteria. If discrepancies or failures are detected, the engine generates alerts, prompting a re-sampling process to ensure accuracy and reliability. The culmination of this auditing effort is the generation of audit-ready reports, crafted to meet compliance standards. These reports are then made accessible to the compliance team through a user-friendly web interface, providing a transparent and efficient means for teams to review and consume the audit findings.

Integrations Middleware & Serializers

BusyBody Limited has a complicated infrastructure and tooling landscape. So there could be more than 1 tool doing a thing Example: Service-team-A provides access to its members using an SSO for Github, and use Kubernetes RBAC for giving granular access to certain pods within a cluster.

For the Access Management control, compliance should be fetching data from Github + K8s cluster for this in-scope service. In order to automate this, we should fetch the records from both systems.

# Github

# Who has access to the Github repo
GET /repos/:owner/:repo/collaborators
# Github: When was the access granted, re-accreditted
GET /repos/:owner/:repo/events

# K8s
GET /apis/rbac.authorization.k8s.io/v1/roles
GET /apis/rbac.authorization.k8s.io/v1/rolebindings
GET /apis/rbac.authorization.k8s.io/v1/clusterroles
GET /apis/rbac.authorization.k8s.io/v1/clusterrolebindings

# logging system 
GET /k8s-audit/logs

After fetching data from both systems. It is ingested into the serializer. The serializer helps create data in a standardized format JSON

# from Github API

{
  "user": {
    "username": "john_doe",
    "email": "john.doe@example.com",
    "full_name": "John Doe"
  },
  "access": [
    {
      "app_name": "github",
      "access_granted": "2024-02-02T12:30:00Z",
      "access_reaccredited": "2024-03-15T09:45:00Z",
      "roles": ["collaborator", "reader"]
      "metadata":
      {
        "repo_name": "example-repo",
      }
    }
  ]
}

# from K8s and Logging systems

{
  "user": {
    "username": "john_doe",
    "email": "john.doe@example.com",
    "full_name": "John Doe"
  },
  "access": [
    {
      "app_name": "k8s_cluster",
      "access_granted": "2024-02-21T12:30:00Z",
      "access_reaccredited": "2024-03-15T09:45:00Z",
      "metadata": 
      {
        "namespace": "default"
        "roles": ["cluster-admin", "view"]
      }
    }
  ]
}

The “Access Management Serializer,” “Vulnerability Management Serializer,” and “Change Management Serializer” are components designed to facilitate the integration and data exchange between specific systems within an organization. Each serializer is tailored to a particular domain, ensuring seamless communication and data flow for effective management of access, vulnerability, and change-related information.

Access Management Serializer:

• HR System
• SSO/LDAP Server
• Any other service maintaining user lists

Functionality:

• The Access Management Serializer serves as a mediator between the HR system, the Single Sign-On (SSO)/LDAP server, and potentially another service managing user lists.
• Utilizing APIs, the serializer fetches relevant data from the HR system, which typically contains employee information, roles, and access permissions.
• Similarly, it interacts with the SSO/LDAP server to retrieve user authentication and authorization details.
• If applicable, the serializer extends its functionality to fetch user data from any other designated service maintaining user lists.
• The fetched data is then structured and provided by the serializer for further processing, ensuring that access management systems are synchronized with the most up-to-date user information.

Vuln Management Serializer:

• Vuln Scanner
• Vuln Ticket Manager

Functionality:

• The Vuln Management Serializer facilitates communication between the vulnerability scanner and the vulnerability ticket manager.
• Through the use of APIs, the serializer retrieves vulnerability data from the scanner, which may include information about identified vulnerabilities, their severity, and affected systems.
• It also interacts with the vulnerability ticket manager, fetching details about the tickets created in response to identified vulnerabilities.

Change Management Serializer:

• Ticketing System
• Version Control System
• Continuous Integration/Continuous Deployment (CICD) System

Functionality:

• The Change Management Serializer acts as a bridge between the ticketing system, version control system, and CI/CD system.
• Leveraging APIs, the serializer fetches relevant data from the ticketing system, including details about change requests, approvals, and implementation timelines, roll-backs, etc
• It communicates with the version control system to obtain information regarding code changes, version history, and associated documentation.
• Additionally, the serializer interacts with the CICD system to access details about automated build and deployment processes. It also checks if the tests have passed for a particular deploy

Conclusion

In conclusion, this should prove that automated complaince is not only theory but a reality. the GRC practitioners of the now and future should watch out for this skill set, as there is becoming a trend of adoption of automation and AI

I hope this blog post gives a high-level understanding on how should the architecture for a GRC Automation tool look like! Feel free to connect with me if you want to talk/nerd out about such things.

• LinkedIn: https://www.linkedin.com/in/m49d4ch3lly
• Twitter: https://twitter.com/m49D4ch3lly
• GitHub: https://github.com/UFarouk10
• Gmail: Umarfarouk037@gmail.com

GRC Engineering Series: Let’s Design an Automated Enterprise Compliance System was originally published in Coinmonks on Medium, where people are continuing the conversation by highlighting and responding to this story.

In the modern enterprise, the Governance, Risk, and Compliance (GRC) function is undergoing a radical evolution. For decades, GRC has been characterized by the popular spreadsheets, yearly/periodic audits, and a “check-the-box” mentality. However, the sheer velocity of data and the complexity of global regulations have made these traditional methods obsolete.

Today, the smart and modernized GRC teams are turning to AI to manage the overwhelming scale of modern business risks. By integrating Machine Learning (ML), Natural Language Processing (NLP), and Predictive Analytics into their workflows, organizations can move toward a “Continuous Compliance” model that identifies threats before they manifest.

The Current State of GRC and the Need for Transformation

Before we explore the technical implementation, we must acknowledge why the status quo is evolving. Most GRC teams currently operate in a state of “Information Overload.” The spreadsheets no longer give an overview of the relevant data, and even diagrams are becoming a chore to look at.

The Regulatory Explosion

In the past 2–3, we have seen a record-breaking number of regulatory updates across the globe on matters of AI and the implication of the adoption of it, from the EU AI Act to evolving ESG (Environmental, Social, and Governance) reporting standards, to the USA Executive Order 14179

Executive Order 14179

Executive Order 14179, issued in January 2025, reorients U.S. AI policy by revoking the 2023 Executive Order 14110 on “Safe, Secure, and Trustworthy Development and Use of Artificial Intelligence.” Its core objective is to eliminate federal policies perceived as impediments to innovation and U.S. dominance in AI.

The order prioritizes national security by directing agencies to enhance U.S. dominance in AI technologies. While it doesn’t establish new cybersecurity requirements, it mandates that the federal government identify and remove existing policies that could obstruct the secure development of AI systems critical to national interests.

The order does not create new privacy standards but implicitly affects data governance by revoking previous directives, including those that emphasized data transparency and protection. This rollback may influence how federal agencies and private sector actors interpret and implement privacy safeguards in AI deployments.

A human compliance officer cannot possibly read, interpret, and map every single change to internal controls across a global enterprise.

USA: AI Bill of Rights

The Blueprint for an AI Bill of Rights, released by the White House Office of Science and Technology Policy in October 2022, outlines a set of five principles intended to guide the design, use, and deployment of AI systems in the United States. While non-binding, the blueprint provides a foundational framework for federal agencies, private companies, and developers to promote accountable AI practices.

The blueprint advocates for AI systems to be safe and effective, requiring pre-deployment testing, risk identification, and ongoing monitoring to ensure they operate as intended and do not cause harm.

It emphasizes that users should have control over how their data is collected and used, with built-in protections against intrusive surveillance and misuse.

The five principles are:

1. Safe and effective systems: AI systems should be subject to pre-deployment testing, risk identification, and ongoing monitoring to ensure they operate as intended and do not cause harm.
2. Data privacy: Users should have control over how their data is collected and used, with built-in protections against intrusive surveillance and misuse.
3. Notice and explanation: People should be informed when an AI system is being used and provided with clear explanations about how it functions and affects them.
4. Human alternatives, consideration, and fallback: Individuals should be able to opt out of AI-driven processes and access human decision-making when needed, especially in high-stakes contexts.

Though not enforceable by law, the blueprint has influenced federal procurement guidelines, agency risk assessments, and sector-specific AI governance initiatives. It reflects the U.S. government’s broader strategy of promoting trustworthy AI through voluntary standards, secure design, and public engagement.

Canada: Artificial Intelligence and Data Act (AIDA)

AIDA focuses on high-impact AI systems, requiring risk assessments, transparency, human oversight, and robustness to ensure safety and accountability.

The act aims to protect individuals by aligning with existing Canadian legal frameworks like privacy, consumer protection, and human rights legislation, ensuring responsible development and use of AI technologies.

China: Generative AI Regulation

China’s regulatory framework for generative artificial intelligence is anchored in the Interim Measures for the Management of Generative Artificial Intelligence Services (“AI Measures”), which took effect on August 15, 2023. These measures mark China’s first administrative regulation directly targeting generative AI and are enforced by a coalition of state agencies led by the Cyberspace Administration of China.

The AI Measures apply to all organizations providing generative AI services to the public within China, regardless of their country of incorporation. While sector-agnostic in scope, the rules interact with other AI-relevant laws such as the Cybersecurity Law, Personal Information Protection Law (PIPL), and various sector-specific guidelines in finance, healthcare, and automotive industries.

It states that providers must maintain the security and reliability of their systems. In addition, providers are required to prevent the generation of illegal or harmful content.

The measures mandate lawful data use, requiring providers to obtain user consent, respect intellectual property, and ensure the legal sourcing of training data.

OECD AI Principles

The OECD’s Recommendation on Artificial Intelligence — adopted in 2019 and updated in 2023 and 2024 — is the first intergovernmental standard promoting trustworthy AI. It establishes five principles for responsible AI development and five recommendations for national and international action. These principles aim to ensure AI systems are human-centric, trustworthy, and aligned with democratic values and human rights.

Principles for Trustworthy AI

• Inclusive growth, sustainable development, and well-being: AI should benefit people and the planet by improving human capabilities, promoting inclusion, reducing inequality, and supporting environmental sustainability.
• Respect for the rule of law, human rights, and democratic values: AI actors must uphold freedoms, dignity, equality, and rights throughout the AI lifecycle. Mechanisms should protect against misuse and ensure human oversight.
• Transparency and explainability: Stakeholders should understand how AI systems operate. Providers must disclose information about data sources, logic, and decision-making processes in a clear and context-appropriate way, enabling users to challenge outputs where needed.
• Robustness, security, and safety: AI systems should function reliably in various conditions and be designed to prevent and mitigate harm. Systems must be overridable or decommissioned when needed and support information integrity.
• Accountability: AI actors are responsible for ensuring systems function correctly and in line with these principles. They must enable traceability of data and decisions, apply risk management at all lifecycle stages, and collaborate with other stakeholders to address issues like bias and rights violations

The Data Silo Problem

Risk data is often scattered across HR systems, financial databases, IT logs, and third-party portals. Risk management as is popularly done relies on people manually gathering this data, which leads to risk assessments that are out of date by the time they are reviewed. Hence the need for continuous and an automated risk management.

The Objective Reality of AI

Unlike humans, AI does not suffer from “fatigue.” It can analyze millions of data points with consistent objectivity, identifying the patterns of anomaly , non-compliance and non-conformity that would be invisible to even the most seasoned auditor.

AI Technologies for GRC Teams

To implement AI effectively, GRC teams must understand the tools at their disposal. We are moving beyond simple automation into the realm of cognitive computing.

Natural Language Processing (NLP)

NLP is the “translator” between human language and machine action. For GRC, this means the ability to ingest large legal documents and extract specific obligations in a short time.

NLP identifies the “who, what, and when” of a regulation, allowing for automated policy updates.

Machine Learning (ML) and Anomaly Detection

ML models thrive on historical data. By feeding an ML model three years of “clean” financial and operational data, it learns the baseline of “normal” behavior.

When a transaction occurs that deviates from this baseline, even slightly, the system flags it for review. This is the heart of modern risk management.

Generative AI (GenAI)

The newest frontier for GRC teams is GenAI. While it must be used cautiously, it is exceptionally good at drafting policy language, summarizing audit reports, and creating “Plain English” explanations of complex compliance requirements for non-expert employees.

Practical AI Use Cases for GRC Teams

The integration of AI into risk management isn’t about replacing human judgment; it is about providing humans with higher-quality data and more time for strategic decision-making. Here are seven practical use cases for modern GRC teams.

Automated Regulatory Change Management

The Challenge: Global organizations operate across a fragmented landscape of local, federal, and international laws. Manually tracking updates from bodies like the SEC, the European Commission, or the MAS involves thousands of hours of legal review. By the time a human identifies a change, the organization may already be in a period of non-compliance.

The AI Solution: Using Natural Language Processing (NLP), Regulatory technology “RegTech” platforms ingest real-time feeds from government portals and legal databases. The AI wouldn’t just “read” the text; it would classify it by “intent.” It then identifies whether a change is an amendment to an existing obligation or a brand-new mandate.

• The “Gap Analysis” Mechanic: The AI automatically compares the new regulatory text against your existing internal control framework. If a new data privacy law requires a 72-hour breach notification and your current policy says 96 hours, the AI flags this specific discrepancy.

Technical Benefit: This shifts the compliance lifecycle from a batch process (monthly reviews) to a stream process (real-time updates), reducing the time between a legal change and a control update from months to minutes.

Dynamic Third-Party Risk Management (TPRM)

The Challenge: Traditional TPRM relies on “point-in-time” assessments. A vendor might look secure during an annual audit in March, but suffer a major breach a month later. GRC teams are often the last to know, leaving the supply chain vulnerable.

The AI Solution: AI enables Continuous Monitoring by aggregating unstructured data from across the web.

• Cyber Intelligence: Scans the dark web for leaked employee credentials or database dumps belonging to your vendors and threat intelligence tools.
• Sentiment & Financial Analysis: Uses NLP to analyze news reports and financial filings for “signals of distress,” such as sudden layoffs or litigation.

Risk Impact: This provides a “Risk Velocity” metric. If a critical cloud provider has a security incident, your GRC team is alerted within minutes via an automated trigger, allowing you to move data or switch to failover systems before the impact becomes catastrophic.

Predictive Operational Risk Modeling

The Challenge: Most risk management is lagging; it tells you what went wrong yesterday. Static risk mapping are often based on subjective metrics from decision makers.

The AI Solution: Predictive Analytics and Monte Carlo Simulations transform risk into a mathematical probability. By feeding the AI historical data, such as system downtime, employee turnover rates, economic indicators, and even weather patterns, the model runs thousands of “what-if” scenarios.

• The Mechanic: The AI identifies correlations that humans might miss, such as a correlation between high employee burnout in a specific region and an increase in data entry errors that lead to financial risk.

Strategic Value: This allows leadership to practice “Proactive Capital Allocation.” Instead of setting aside funds for a disaster, you invest in the specific controls (like hiring or system upgrades) that the AI predicts will most effectively lower the “Value at Risk” (VaR).

Audit Coverage (The End of Sampling)

The Challenge: Due to time constraints, internal auditors use statistical sampling, checking perhaps 100 out of 1,000 invoices. This leaves a blind spot where non-conformity or errors can hide.

The AI Solution: AI-enabled audit tools utilize Machine Learning (ML) Anomaly Detection to process the entire population of data.

• Transaction Analysis: The AI scans 100% of general ledger entries, T&E (Travel and Expense) reports, and system access logs.
• Pattern Recognition: It looks for “Benford’s Law” deviations or unusual “time-of-day” entries (e.g., an accountant approving a massive wire transfer at 3:00 AM on a Sunday).

The Result: “Total Visibility.” The audit shifts from a “detective” control to a “deterrent” control. When employees know every transaction is being screened by AI, the rate of “accidental” non-compliance drops significantly.

AI-Powered Internal Policy Management

The Challenge: Most corporate policies are buried in 100-page PDFs on a dusty intranet. When employees find them too difficult to navigate, they make guesses, leading to “shadow compliance” or accidental violations.

The AI Solution: Implementing a Generative AI (GenAI) interface, often called a “Compliance Bot,” trained exclusively on your internal policy documents.

• Semantic Search: An employee can ask, “Can I accept a $200 dinner from a vendor in Singapore?” The AI cross-references the Global Anti-Bribery Policy with the regional Singapore annex and provides an instant answer.

Culture Impact: This democratizes risk management. It moves compliance out of the legal department and into the hands of the frontline staff, fostering a culture of “Compliance by Design.”

Automated Evidence Collection for SOC2, HIPAA, and ISO 27001

The Challenge: The “Evidence Scramble” is the most hated part of GRC. It involves dozens of people spending weeks taking screenshots of AWS configurations, Jira tickets, and HR onboarding logs to prove to auditors that controls are working.

The AI Solution: API-driven AI agents create a persistent “Evidence Data Lake.”

• Automated Verification: Instead of a human checking if “Multi-Factor Authentication is enabled for all users” once a year, the AI agent checks the configuration via API every hour.
• Timestamping & Storage: The AI automatically captures the proof, timestamps it, and maps it to the relevant SOC2 or ISO control.

Efficiency Gain: This transforms the audit from a “fire drill” into a “non-event.” When the external auditor arrives, the GRC team simply provides access to the pre-populated evidence vault, reducing audit prep time by up to 80%.

7. Fraud Detection and AML (Anti-Money Laundering)

The Challenge: Money laundering often involves “layering”, moving money through a complex web of accounts to hide its origin. Traditional rule-based systems (e.g., “flag any transfer over $10k”) are easily circumvented by “smurfing” or smaller, frequent transfers.

The AI Solution: Graph Neural Networks (GNNs). Unlike traditional databases, GNNs focus on the relationships between data points.

• The Mechanic: The AI maps the entire network of transactions. It can detect a “Cycle” (Money moving from Person A to B to C and back to A) or a “Hub and Spoke” pattern that is a hallmark of criminal activity.

Compliance Benefit: This significantly reduces “False Positives”, the bane of AML teams , while catching sophisticated “low-and-slow” fraud patterns that would never trigger a standard rule-based alarm.

Roadmap for the Implementation of AI

For GRC teams ready to start, the implementation should be handled in phases to ensure data integrity and team buy-in.

Phase 1: The Data Foundation

AI is only as good as the data it has consumed.

• Audit your data: Where is your risk data stored? Is it secure?
• Centralization: Move from disconnected spreadsheets to a centralized GRC platform that supports API integrations.
• Standardization: Ensure that “Risk Level High” means the same thing in the IT department as it does in the Finance department. Establishing a quantifiable metric for risk levels is

Phase 2: The Pilot Program

Don’t try to automate everything at once. Pick a low-impact, low-complexity task.

• Recommended Pilot: Third-Party Risk or Regulatory Tracking.
• Goal: Demonstrate that the AI can catch a risk that a human missed, or save a specific number of work hours.

Phase 3: Integration and “Human-in-the-Loop”

AI should augment humans, not replace them.

• Define the Workflow: The AI identifies a potential risk, but a human GRC professional must “adjudicate” it.
• Feedback Loops: When a human corrects the AI (e.g., “This isn’t actually a fraud risk”), the system learns from that correction to improve future accuracy.

Phase 4: Scaling and Governance

Once the pilot is successful, scale to other risk domains (Cyber, ESG, Finance).

• Establish an AI Ethics Committee: Monitor your own AI for bias. Ensure the models are “Explainable” (XAI) so you can tell a regulator exactly why the AI made a certain decision.

Managing the Challenges of AI in GRC

Implementing AI for risk management is not without its pitfalls. GRC teams must be prepared for three specific challenges:

The “Black Box” Problem

In highly regulated industries like banking or healthcare, “the AI told me so” is not an acceptable answer for a regulator.

• The Solution: Prioritize “Explainable AI.” Choose vendors that provide a clear trail of logic for every risk flag.

Algorithmic Bias

If your training data contains historical biases (e.g., in hiring or lending), the AI will replicate and accelerate those biases.

• The Solution: Regular “Bias Audits” of your AI models. GRC teams should treat their own AI systems as “high-risk vendors” that require constant oversight.

Data Privacy and Security

Sending sensitive corporate data to a public AI model (like the free version of ChatGPT) is a massive risk.

• The Solution: Use private, “Single-Tenant” AI instances. Ensure that your data is not being used to train the provider’s general model.

The Strategic ROI of AI-Enabled Risk Management

The return on investment for AI in GRC is measured in three ways:

Cost Avoidance

Avoiding a single multi-million dollar GDPR fine or a ransomware payout pays for the AI implementation ten times over.

Operational Velocity

When compliance is automated, the business can move faster. New products can be launched in new countries without waiting six months for a manual compliance review.

Strategic Focus

GRC professionals stop being “data hunters” and start being “risk strategists.” They spend their time advising the CEO on high-level strategy rather than chasing down audit logs.

Conclusion

For GRC teams, the implementation of AI is a journey, not a destination. As the technology evolves, so will the risks it manages. The organizations that thrive in the coming decade will be those that treat AI as a core member of their risk management team.

By automating the mundane, predicting the unforeseen, and providing 100% visibility into compliance, AI will transform GRC from a “necessary evil” into a powerful engine for organizational trust and resilience.

Automation Series: Theory of Implementing AI in Risk Management was originally published in Coinmonks on Medium, where people are continuing the conversation by highlighting and responding to this story.

Why do we need security compliance automations?

Automating your security compliance will mean different things depending on who you speak to. For me, and for the context of this blog post I define security compliance automations as “Software tools that can reduce the repetitive tasks for engineering, infrastructure, security, product, and legal teams in attaining security compliance”.

Audit Automations vs Control Automations

At a glance, the distinction between audit and control automations might seem subtle, but understanding their core functionalities is crucial for any technical professional working in the realm of security compliance.

Why do we need them both ? Audit Independence. This is a concept that internal audit teams are familiar with which ensures that people/tools operating a process and the ones that check that process are independent

Audit automation tools primarily focus on assessing and verifying if specific control requirements are fulfilled.

They are instrumental in preparing detailed audit reports, highlighting areas of adherence or discrepancies. For instance, such a tool would validate if the Service Level Agreement (SLA) for addressing each vulnerability has been met within the stipulated time frame. On the other hand, control automation operates on the front lines, actively enforcing or implementing security measures to meet these requirements. It’s the system that takes proactive action, such as deploying automated patches for known vulnerabilities. So, while audit automation ensures that we are aware of our compliance status, control automation ensures that we are actively compliant.

Designing your compliance with an automation-first approach

Okay, so now you know the difference between control automations and audit automations. Here are the things you can do if you are building a new security or compliance function (treat this like a checklist):

Understand context and scope: Having an understanding of your infrastructure (cloud or on-premises), the application stack and the blast radius for your organization is key to start defining your security or compliance program. This will help you pick the right tools . Your approach would differ if you are a mid-size SaaS company primarily relying on AWS vs a legacy finance company that is running Linux hosts in a data center(lab series on the latter).

Security teams come in various shapes and sizes. Depending on the business, the security team might belong to engineering or legal teams or could be a separate entity reporting to the CEO. This impacts the functioning of the security program in multiple ways, we will focus on the impact in the compliance program

If the compliance function sits within engineering, the team may have supportive peers to help with getting things (mostly with infrastructure controls) done, especially around compliance tooling. Since the broader group reports to the Head of Engineering (title may wary), there is enough incentive to get things rolling fast. It gets harder if the compliance/security sits with legal, since there is less incentive for software and product engineers to support compliance. Compliance is then seen as “yet another thing to do” that is not directly contributing to the feature set and revenue.

Identify Stakeholders: Meet with people that are affected by things you do. Understand why they don’t want you to do the things. Are they engineering teams that are expected to operate and own the security control ? or are they decision makers within the business? These are the people who would want to help first with your tooling. Reducing engineering toil with automated tooling should be a priority.

Build a culture: Traditional security teams wouldn’t want to automate things. People don’t like the idea of python scripts replacing their jobs. You need to create a culture with a narrative that automated tools do the boring and mundane work (e.g.: validating evidences) so that the security and compliance teams can focus on the changing landscape of privacy and security regulations. These automated tools act like swords, you still need someone to operate them and are better than fighting with bare hands

Understanding the underlying technology (infrastructure)

My writing will focus significantly on infrastructure since compliance programs focus on having things on the infrastructure configured securely. Compliance certification (PCI, ISO27001, SOC2, SOX) requirements are generic and may have different reporting requirements, however, having a secure infrastructure is a common theme across all certifications. Moreover, the size and complexity of the their technology stack tells a good story of their maturity and pace at which they like to operate.

Lets look at two companies;

1) Company A : A small-stage Business-to-Business Software as a Service (B2B) SaaS company has recently achieved SOC 2 certification. The company runs its application primarily on Amazon Web Services, using a relatively simple cloud architecture.

The company’s goal is to maintain security and compliance while scaling revenue and engineering velocity ahead of its Series B funding round.

Infrastructure

The product stack is intentionally simple enough to secure effectively.

Typical architecture would look like:

Users
  |
Load Balancer (AWS App LB)
  |
EC2 Application Servers
  |
Managed Database
  |
S3 Storage

The analytics pipeline pulls aggregated product data from the database for internal reporting.

To keep risk manageable, the company relies on a small number of critical SaaS platforms. The goal is to avoid SaaS sprawl, which can overwhelm a small security team.

Security Priorities

The team focuses on four manageable domains.

Identity & Access Management

Control access to:

• AWS accounts
• production systems
• SaaS tools
• developer repositories

Focus areas:

• SSO enforcement
• MFA everywhere
• role-based access

Cloud Security

Protect the AWS environment by monitoring:

• IAM privilege changes
• EC2 configuration
• S3 access policies
• network security groups

This reduces the risk of cloud misconfigurations.

Security Monitoring

Centralized logging is implemented so the team can detect incidents quickly.

Primary logs monitored would include:

• AWS activity logs
• authentication events
• system logs from EC2 instances
• application access logs

Alerts are triaged by the Security Operations Engineer (title may vary).

Compliance & Audit Readiness

The GRC analyst manages:

• SOC2 control evidence
• security questionnaires
• third-party risk reviews
• policy updates

Automation is used where possible to reduce manual work.

Security Tooling

A small security team typically maintains a focused stack rather than dozens of tools. The objective is operational simplicity and automation.

2) Company B :A publicly traded enterprise that generates over $20B in annual revenue and employs 20,000+ people globally.

This company operates several independent lines of business, including:

• digital platforms
• enterprise services
• customer products
• internal financial services
• data analytics operations

Because the company grew over decades, much of its technology stack was built internally and runs inside company-owned data centers.

Over the past decade the company has gradually adopted hybrid cloud infrastructure, primarily using Amazon Web Services and Microsoft Azure for scalable workloads. Despite its size, the company operates under public market financial discipline, meaning budgets are large but scrutinized heavily.

Organizational Structure

Technology operations are distributed across multiple business units, each running its own engineering and infrastructure teams.

Typical structure:

Units: Corporate IT, Platform Engineering, Data & Analytics, Product Engineering, Infrastructure Operations.

Because these units evolved independently, the environment contains multiple technology standards and legacy systems.

Infrastructure Model

The company operates three main infrastructure environments.

Enterprise Data Centers

Most mission-critical systems still run in company-owned facilities.

Infrastructure includes:

• large virtualization clusters
• internal storage networks
• enterprise databases
• custom orchestration platforms

The company also maintains internal tooling for provisioning and monitoring infrastructure.

Hybrid Cloud Environments

Over the last decade, certain workloads have moved to cloud environments.

Common cloud workloads:

• web front-end applications
• data analytics
• burst compute workloads
• development environments

Cloud providers include:

• Amazon Web Services
• Microsoft Azure

These environments are integrated with internal networks through private connectivity and identity federation.

Legacy Systems

Some business-critical systems remain on older enterprise platforms, including:

• legacy financial systems
• long-running customer databases
• proprietary operational platforms

These systems often require specialized expertise to maintain.

Security Organization

Unlike startups, the company maintains dedicated teams across the entire security lifecycle.

Approximate security staffing: 80–120 professionals.

Core groups include:

Security Engineering, Security Operations, Cloud Security, Application Security, GRC, Internal Audit.

Even with this staffing, the organization constantly competes for budget and organizational support.

Compliance Environment

Because the company is publicly traded, it must comply with multiple regulatory frameworks.

Typical obligations include:

• SOX financial controls
• ISO 27001 information security management
• regional data protection laws
• contractual enterprise security requirements

Compliance oversight involves coordination between:

• GRC teams
• internal audit
• legal counsel
• business unit leadership

Security Challenges

Despite significant resources, the company faces systemic security challenges.

Infrastructure Fragmentation

Because systems evolved over decades:

• multiple monitoring tools exist
• inconsistent security controls appear across environments
• different business units operate differently

Legacy Risk

Older systems may:

• lack modern security features
• require outdated software dependencies
• be difficult to patch or replace

Hybrid Visibility Gaps

Monitoring must cover:

• on-premise data centers
• hybrid cloud environments
• internal corporate networks

Achieving unified visibility across these environments is difficult.

Organizational Complexity

Security initiatives often require cooperation from:

• infrastructure teams
• product engineering teams
• business unit leadership

Projects can stall due to political and operational friction.

Security Tooling Environment

The enterprise operates a large but structured tool ecosystem.

Key categories include:

FunctionCapabilityIdentity managementEnterprise directory servicesSecurity monitoringSIEM and SOC toolingEndpoint securityEnterprise EDRNetwork protectionIDS/IPS platformsCloud monitoringCloud security posture toolsVulnerability managementEnterprise scanning platforms

Security teams must integrate cloud telemetry, on-prem logs, and application activity into centralized monitoring.

Strategic Security Priorities

Security leadership typically focuses on four long-term initiatives.

Hybrid Security Architecture

Create unified security controls across:

• data centers
• cloud environments
• internal corporate networks

Identity Modernization

Centralize authentication and authorization across the enterprise.

Security Automation

Reduce manual compliance and monitoring processes through automation.

Risk Reduction in Legacy Systems

Gradually modernize or isolate older platforms that present security risks.

Operational Reality

Even with significant resources, the security organization constantly balances:

• regulatory compliance
• operational stability
• budget limitations
• competing business priorities

Security programs therefore evolve incrementally, rather than through rapid transformation.

Compliance certification requirements will be interpreted differently for both companies. One will be a lot more challenging to operate and automate for audits. These are two extremes so your organization would sit somewhere in-between the two examples.

Below is a scribbled diagram of the company size, infrastructure style and how complex would it be to automate their compliance audits.

Even thought it is complicated, such organizations should consider automating their audits due to the incredible return on investment it offers.

Vendor tool selection

If you are Company A., you can simply pick any of compliance automation tools(we will do that in a future blog) and you can achieve automation for 75–80% of your painful controls, open source tools would provide a lot of value here.

If you are Company B, you should be setting aside resources to build a GRC Engineering Team to help you build these tools. They will start with one control one certification, and work their way through solving the scaling problem.

If you are somewhere in the middle (most companies out there). You may not get the support for building a dedicated team that does the development of tools. You can possibly get a vendor tool for some of the controls and automate them with accuracy and completeness. For the controls that require integrations with custom tooling, you can write simple python scripts that run off your laptop. If you use Google Sheets and your auditors enjoy spreadsheet-like evidences, you can use the Apps Scripts to pull auditable data. Once you have multiple such scripts that have time-and-again proved that scripts have saved time, reduced human error, you can asked for a dedicated headcount for developing more such automations. Proving that your scripts have been useful for compliance testing is important to get buy-in from leadership.

Architecture for enterprise-grade GRC Automation tool

Conclusion

Automation is not about replacing compliance teams; it is about scaling their effectiveness. Whether you operate a lean SaaS startup or a complex enterprise with decades of infrastructure, the core challenge remains the same: proving that security controls exist and work consistently.

An automation-first mindset reduces repetitive evidence collection, minimizes human error, and frees teams to focus on real risk management instead of manual reporting. Start small, automate one control, one audit requirement, or one workflow. Over time, these incremental improvements compound into a resilient compliance program where security, engineering, and audit teams collaborate through systems rather than spreadsheets.

In the next article, I will tackle one of the use cases, expand on it, tools and hopefully design and implement an automation lab.

I hope I provided value in this piece. I hope you have found value in today’s article. Consider clapping, subscribing and following me on my socials. If you need to reach me , I am a DM away.

• LinkedIn: https://www.linkedin.com/in/m49d4ch3lly
• Twitter: https://twitter.com/m49D4ch3lly
• GitHub: https://github.com/UFarouk10
• Gmail: Umarfarouk037@gmail.com

GRC Engineering Series: Let’s Design an Automated Compliance System was originally published in Coinmonks on Medium, where people are continuing the conversation by highlighting and responding to this story.

I haven’t written about GRC in quite a bit. This feels like a writeup that will be both rewarding for myself and the reader(s)

I always take offense when people go “GRC is for non-technical people,” and “GRC professionals do not need to know scripting or networking.” :) I have always preached adding another domain as a complementary specialization in this space (ala networking, automation, SOC, pen testing, vulnerability assessment etc.) to your repertoire of skills.

Now, I was apparently ahead of the curve all along (thank God because the job market is crazy) , now there’s a bit of a shift happening with respect to job roles and their requirements. To think I might have been an engineer not an analyst all this while.

If you want to be relevant in the next decade, you DO need to know coding or some other specialization in tech or a cybersecurity domain.

What Is GRC Engineering?

GRC engineering treats deliverables like governance, risk management and compliance like an engineering problem.

• Define the your controls.
• Automate the checks.
• Integrate them into existing infrastructure, processes or/and platforms.
• Surface real-time evidence for leaders and auditors.

No more screenshot circus. No more annual panic. Just continuous assurance, embedded in the way you ship and operate.

Why Now?

This shift toward GRC engineering did not happen overnight, if you take a look at other domains you would find a similar path had been threaded. It’s being driven by forces that make the old “annual audit” model unsustainable.

First, change cycles have outpaced audit cycles. In most companies, code gets deployed daily, sometimes hourly. Infrastructure is ever changing, and AI systems constantly retrain, update, and change behavior. Trying to govern all that with quarterly reviews and static checklists is like trying to track the weather with last month’s forecast .. you’ll always be behind.

Second, stakeholders want proof, not promises. Enterprise customers no longer settle for policy binders and generic assurances. They want evidence in real time: uptime metrics, incident closure times, and access attestation reports. If you can’t produce them, you’re not just behind on compliance.. you’re leaving money on the table. In many industries, GRC engineering has become a revenue enabler, as it enables startups and enterprises to demonstrate trust instantly, rather than after weeks of scrambling.

Third, regulators have simply raised the bar.

• NIST CSF 2.0 moves away from “box-checking” and emphasizes measurable outcomes.
• ISO Standards are forcing closer alignment between risks and controls, demanding traceability between what you say and what you do.
• PCI DSS 4.0 requires continuous evidence of controls for cardholder environments. The era of once-a-year screenshots is over.

Put simply, the speed of change, customer expectations, regulatory pressure, and financial realities are converging. GRC engineering is no longer a nice-to-have. It’s the only way to keep up.

What is the GRC Engineering Landscape?

A GRC-engineered environment feels very different from traditional compliance. Instead of a scramble before audit season, governance and assurance are baked into the daily flow of engineering and operations.

A regulator sends a routine request: “Please provide evidence that privileged access to production systems is reviewed quarterly.”

Old World:

What should be a simple request quickly becomes chaos.

The GRC team sends messages across Slack channels asking for help. Someone from the identity team exports a CSV from Active Directory. Another engineer searches through ServiceNow for access review tickets. A cloud administrator screenshots Azure role assignments.

None of the data lines up.

Usernames don’t match employee IDs. Some accounts belong to contractors who left months ago. One of the exported spreadsheets is already two weeks old. The SOC analyst notices several privileged accounts that were never part of the last access review. Now the question shifts from “Where is the evidence?” to “Were the reviews actually done?”

Days turn into weeks.

Spreadsheets are merged. Screenshots are annotated. Someone pastes explanations into a long email thread trying to justify the inconsistencies. Eventually, the evidence package is assembled into a bulky document. By the time it reaches the regulator, the access list has already changed again. The audit deadline is approaching, confidence is fading, and the uncomfortable realization sets in:

the organization doesn’t actually have a reliable way to prove that its own access control policies are working.

GRC-Engineered World:
The GRC analyst opens the access governance dashboard. The system continuously tracks privileged roles across the identity provider, cloud platforms, and on-premise infrastructure. Every account with administrative permissions is already mapped to an owner, a ticket, and a review cycle.

Within seconds, the dashboard shows the current status.

All privileged accounts are listed with their last review date, approving manager, and expiration policy. The system highlights that the most recent quarterly review closed two weeks ago, with 98% of access requests approved and two unnecessary permissions automatically revoked during the process.

Exporting the evidence takes less than a minute.

The report includes:

• a complete list of privileged accounts
• the timestamp of the last quarterly access review
• manager approvals captured in the identity governance workflow
• remediation logs showing where privileges were removed

Every action is tied to audit logs pulled directly from the identity platform.

No screenshots.
No spreadsheets.
No hunting through ticket systems.

The evidence is generated directly from the systems enforcing the control. The customer receives the report the same day, complete with machine-generated timestamps and approval records.

Confidence is built immediately.

That’s the difference between traditional governance and a GRC-engineered environment.

In the old model, access reviews are periodic events. Someone exports a user list, emails managers for confirmation, and hopes everyone responds before the deadline. Evidence is assembled after the fact, often from incomplete records.

In a GRC-engineered system, the control operates continuously. Privileged accounts are automatically identified through role tagging and policy definitions. Review workflows are scheduled within the identity governance platform, triggering approval tasks for managers every quarter. If approvals aren’t completed on time, reminders escalate automatically.

If a privileged account becomes inactive or unnecessary, the system flags it or removes it automatically. Every approval, rejection, and privilege removal is logged in real time. The control is not just documented.
It is enforced.

The identity infrastructure effectively becomes its own audit trail. Joiner-mover-leaver processes from the HR system trigger identity updates automatically. When employees change roles, privileged permissions are re-evaluated. When someone leaves the organization, access disappears immediately across production systems.

Quarterly reviews don’t require manual coordination because the workflow already exists inside the identity governance platform.

• Approvals happen inside the system.
• Evidence is captured automatically.
• Audit artifacts are generated by default.

From a leadership perspective, this environment removes uncertainty. Instead of waiting for auditors or customers to uncover gaps, dashboards show real-time indicators such as:

• number of active privileged accounts
• percentage of accounts reviewed in the current cycle
• stale privileges awaiting removal
• average time to approve or revoke access

The organization doesn’t need to prove that access reviews happened. The system proves it continuously. For engineers and administrators, the change is equally significant. Access management stops being a periodic administrative exercise and becomes a governed workflow embedded in the identity platform.

Requests, approvals, revocations, and evidence all happen within the same system. Compliance stops interrupting operations and instead becomes a natural byproduct of how access is managed. And when the next request arrives asking for proof that privileged access is reviewed quarterly, the answer isn’t assembled.

It’s already there.

The Skills GRC Pros Need Now

1. Identity and Access Management (IAM)

The Problem

IAM is one of the most control-heavy domains in cybersecurity, but it often suffers from:

• Manual access reviews
• Excessive privileges
• Poor role definitions
• Slow onboarding/offboarding process
• Compliance checks done quarterly instead of continuously

From a GRC perspective, these create access risk, segregation-of-duty violations, and audit failures.

How GRC Engineering Solves It

1. Policy-as-Code for Access Controls

Instead of documenting access policies in PDFs, GRC engineers encode them into systems.

Example:

• “Finance staff cannot deploy code to production”
• “Developers cannot approve their own pull requests”
• “Privileged access expires after 24 hours”

Tools such as:

• Microsoft Entra ID
• Fortinet FortiManager
• Cloud access policies (AWS, Azure)

automatically enforce these governance rules.

2. Automated Access Risk Scoring

GRC engineering can calculate risk scores for identities based on:

• Privilege level
• Dormant accounts
• External access
• Privileged group membership

This allows IAM teams to focus on high-risk identities first.

Example automation:

Risk Score = Privilege Level + Dormancy + External Access + Failed Logins

Accounts above threshold → automatically flagged for review.

3. Continuous Access Certification

Instead of quarterly access reviews, GRC engineering integrates IAM with:

• HR systems
• ticketing platforms
• asset inventories

This enables continuous access governance:

Example workflow:

Employee leaves HR system
 → IAM detects termination
 → Access automatically revoked
 → SOC notified
 → GRC system logs evidence for audit

4. Segregation of Duties (SoD) Automation

GRC engineering can enforce SoD policies such as:

RoleCannot Combine WithPayment approvalPayment creationCode deploymentCode approvalDatabase adminAudit log management

Violations trigger automatic access removal or escalation.

2. Red Teaming

The Problem

Red teams generate valuable findings, but organizations struggle to translate them into:

• risk management
• governance improvements
• measurable control maturity

Many reports become static documents that leadership never operationalizes these data.

How GRC Engineering Solves It

1. Attack Path → Risk Register Automation

GRC engineering converts red team findings into structured risk data.

Example:

Red Team Finding:

Initial Access → Phishing → Domain Admin → Data Exfiltration

Automatically mapped to:

• Risk category
• impacted assets
• control failures
• MITRE ATT&CK techniques

This updates the enterprise risk register automatically.

2. Control Validation Automation

Red team exercises can be tied to control frameworks such as:

• ISO 27001
• NIST CSF
• CIS Controls

Example:

Initial Access → Phishing → Domain Admin → Data Exfiltration

A GRC engineering platform can automatically update control effectiveness scores.

3. Continuous Purple Team Feedback Loops

Instead of annual penetration tests, GRC engineering enables:

continuous adversary simulation

Workflow:

Red team attack simulation
→ SOC detection triggered
→ Detection effectiveness scored
→ Control maturity updated in GRC platform

This links back to the Identity and Access Management (IAM) system in place.

3. Security Operations Center (SOC)

The Problem

SOCs often face:

• Alert fatigue
• Poor prioritization
• Lack of risk context
• Weak linkage to compliance frameworks

A SOC may detect thousands of alerts but not know which ones matter most to the business.

How GRC Engineering Solves It

1. Risk-Based Alert Prioritization

GRC engineering integrates:

• asset criticality
• business impact
• regulatory obligations

into SIEM/SOC alerts.

Example:

AlertAssetPriorityMalware on test laptopLowFailed login on Domain ControllerHighSuspicious activity on payment systemCritical

The SOC should always focus on business-critical incidents first.

2. Compliance-Aware Incident Response

Certain incidents trigger regulatory obligations:

Examples:

IncidentRegulatory RequirementData breachGDPR reportingCritical infrastructure outageNational regulator notificationFinancial data compromiseBanking regulator reportingIncidentRegulatory RequirementData breachGDPR reportingCritical infrastructure outageNational regulator notificationFinancial data compromiseBanking regulator reporting

GRC engineering embeds these requirements into incident response playbooks.

Example automation:

Incident classified as "personal data breach"
 → Compliance workflow triggered
 → Legal notified
 → Breach reporting timer started

3. Automated Control Evidence Collection

SOC tools generate large volumes of logs.

GRC engineering automatically collects evidence from:

• SIEM
• EDR
• IAM systems
• vulnerability scanners

This removes the manual audit evidence collection burden.

Example:

Audit request:

Provide proof of log monitoring controls

GRC platform automatically exports:

• SIEM configuration
• alert logs
• response timelines
• Technical detection to governance metrics.

The GRC pro of the future isn’t just a checklist auditor. They’re a compliance engineer, risk analyst, part automation architect.

The good news is that you do not need to start becoming a part-time coder to get good at GRC engineering. This is where vibe coding and MCP come in.

Vibe Coding and MCP: The Next Leap in GRC Engineering

The story doesn’t end with automation. Emerging paradigms like vibe coding and the Model Context Protocol (MCP) are making GRC engineering even easier and more accessible.

• Vibe coding allows developers and even non-developers to build applications by describing goals in natural language instead of writing full code. Imagine prompting AI to: “Build me a compliance dashboard that tracks IAM misconfigurations and shows trend lines” and having an AI agent generate the first working version. GRC pros don’t need to be full-time engineers; they just need fluency to guide these systems toward secure, compliant outcomes.
• MCP (Model Context Protocol) enables AI agents to plug into organizational systems (like ticketing, logging, or cloud APIs) in a standardized, secure way. Instead of manually wiring integrations, GRC engineers will soon be able to direct AI agents to “collect IAM activity logs” or “test DR failover,” and the agent will handle the details.

Together, vibe coding and MCP lower the barrier to entry for technical GRC. They let professionals focus on what needs to be governed while AI handles the repetitive “how.”

That’s the next frontier: GRC engineering not just as a skillset, but as a collaborative workflow with AI.

The checklist auditor is gone. The compliance engineer is here. And soon, the compliance engineer will have AI copilots that make governance as easy as describing the outcome you want.

Closing….

I think I’m going to start a GRC engineering series, let me know if you would support that, or would videos be better?

I hope you gained value from this piece, show your support with claps, comments and sharing. I hope to read you soon!!

The time of the GRC analyst is gone, now the engineer emerges was originally published in Coinmonks on Medium, where people are continuing the conversation by highlighting and responding to this story.

Some years back, there was an accepted formula for breaking into cybersecurity. Bag a degree, add a few certifications, land a junior SOC or cybersecurity analyst role, and work your way up the ladder. It wasn’t perfect, but it was predictable. In 2026, that predictability is gone. Now that I think about it, that’s basically what our parents preached (from a Nigerian perspective) we should do: degree-certs-entry-level role-climb the ladder by the grace of God (japa).

The industry hasn’t just evolved; the rules have kind of changed if I’m being honest with you. What employers expect, how careers progress, and what actually makes someone valuable in cybersecurity all look very different now. I’m writing from multiple perspectives, as an employer, someone whose career is very much being built, and an aspiring leader in this space.

I’ve spoken to countless people trying to break into L1 SOC roles. Many do the following, rinse and repeat. They build home labs. They learn SIEM tools like Splunk. They understand basic incident response workflows. They pass Security+. They apply to 150 or 200 roles. And then they sit there refreshing LinkedIn, tweaking their CV again, wondering what they missed. The issue isn’t laziness.

If you’re still following advice written from just a few years back, you’re already behind. This isn’t a warning, not a threat but an opportunity. Sit down (or stand who am I to tell you what to do) and brace yourself for the new rules of the game

Capacity >>> Credentials

One of the most significant shifts in today’s job market is how organizations now approach hiring for roles. Academic degrees and lengthy certification lists still matter, but they are no longer the ultimate deciding factors they once were. Employers are increasingly frustrated with candidates who appear outstanding on paper yet struggle when confronted with real environments, real limitations, and real risk-based decisions.

Modern hiring processes now emphasize practical competence over theoretical knowledge. Can you analyze and respond to an incident instead of simply quoting a framework? Can you articulate why a particular security control is effective in one scenario but ineffective in another? Can you design, build, or automate a solution rather than just explain how it should work?

When I hired SOC Analysts last year, they were asked to walk us through some processes, and scenarios, this required them to think for themselves; not recycle something from a book or learning platform

This evolution has quietly reshaped the playing field. Individuals from non-traditional backgrounds are no longer automatically disadvantaged if they can demonstrate genuine, hands-on capability. In many instances, they outperform candidates who followed the conventional academic path but never moved beyond theory, and to top off, my top candidate for the SOC role came from a non-technology related field, very far from it.

Networking will supercharge your chances

I can’t lie, knowing the right people is an unfair advantage. Starting out my career, I had the privilege to know some top people in the industry, they pointed me in the right direction that eventually landed me my first and second jobs in the space.

Connecting with like minded people will add you to the news pool or the “great vine”, where opportunities are shared. If you’re just on community group chats, you’re not doing enough, reach out personally to low-level and high-level person that will advise you and plug you to opportunities.

Agentic AI Is redefining Entry-Level Roles and the job market

Much of the frustration in today’s job market stems from outdated assumptions about what “entry-level” work looks like. In 2026, many of the tasks that once defined junior security roles are no longer performed by people in the traditional sense. L1 SOC and basic vulnerability scanning roles are built around repeatable workflows. You monitor alerts, you triage, you escalate. You run scans, review findings, generate reports, validate against known patterns, and follow documented playbooks. That structure is exactly why these roles existed at scale. It’s also exactly why they are vulnerable now.

What remains is work that requires judgment and it’s expected much earlier in a career. Even junior roles now demand familiarity with cloud environments, identity systems, automation fundamentals, and a practical understanding of how modern infrastructures operate. Entry-level no longer means “learning by doing manual tasks on the job.” Organizations don’t want to have to train staff, at least I’m guilty of that, of course there will be training and capacity building, but it is important that new personnel are able to hit the ground running with their core tasks from the start. It means being capable of contributing meaningfully in a modern, automated environment from the start.

One of the most significant and underestimated shifts driving this change is the rise of agentic AI. This evolution goes beyond smarter dashboards or improved tools. It introduces autonomous and semi-autonomous agents that monitor environments, make decisions, and execute actions with minimal human intervention. Lots of tools are moving from the use of query languages to output data to just prompting an AI agent.

Security professionals are increasingly interacting with agents rather than isolated tools. Instead of manually navigating consoles, they ask systems what is happening, why it matters, and what action should be taken. The human role is shifting from operator to supervisor, strategist, and final authority.

This transformation carries serious career implications. Technical navigation skills matter less than analytical thinking and systems understanding. The most valuable professionals are those who can design guardrails, recognize when automated agents are misbehaving, and intervene when automation introduces new risks.

Agentic AI does not eliminate jobs, it compresses them. It removes shallow, repetitive work and exposes the depth of an individual’s understanding of systems, incentives, and failure modes.

Personal Branding Is No Longer Optional

Another uncomfortable reality of the 2026 job market is that visibility matters. Not because everyone needs to become an influencer, but because trust is often formed long before an interview ever takes place. Once again, with the top interview from last year, the candidate was a person of interest due to the trust built from watching their projects and initiatives on Twitter (now X ewww) and LinkedIn.

Hiring managers, founders, and clients routinely look people up. They read posts, browse articles, scan comments, and observe patterns. They pay attention to who can explain complex ideas clearly, who expresses opinions grounded in experience, and who consistently contributes thoughtful insights.

Personal branding, in this context, is not just self-promotion. It is signaling. It demonstrates how you think, how you reason through trade-offs, and how you communicate expertise. Professionals who write, teach, share lessons learned, or articulate practical insights build credibility long before they apply for a role or pitch a service. In a crowded market, being known for something specific is often more powerful than adding another certification to your résumé.

An equally important mindset shift is recognizing that cybersecurity no longer has to mean traditional employment alone. In 2026, solopreneurship is not fringe, it is viable and increasingly common.

I am not advising you to turn to be a clout chaser, don’t go around posting meme after meme for the clicks, misleading titles and so on, but rather your projects, labs, and challenges. Engage in meaningful conversations with fellow professionals and teach what you know in the public space, remember you never know who is watching or who could stumble on your work. For long term readers, you will remember that my writing opened the door to a job for me so put yourself out there.

Careers Now Look Like Index Funds

The paradigm has changed. Modern cybersecurity careers look more like investment portfolios or a basket of skills and experiences if I may. People move between SOC, engineering, governance, teaching, consulting, and building products, sometimes all at once. An index fund is a diversified basket of asset classes that match the index, they offer broad market exposure, minimal trading, and consistent, long-term returns, making them ideal for beginners and passive investors.

Fractional roles, advisory positions, contract-based jobs and project-based work are increasingly common. Identity is shifting from job titles to reputation and capability. This flexibility rewards those who invest in durable skills rather than tying their identity to a single employer or tool.

Cloud and Identity Have Become Career Anchors

Cloud security is no longer a specialization you should postpone. It is now the default environment for most organizations, and identity has become the primary control plane.

Misconfigurations, over-privileged identities, and architectural shortcuts remain some of the biggest sources of risk. Professionals who understand how identity, networking, application design, and monitoring interact at scale are consistently in demand.

This is also why scripting and automation have become career accelerators. Manual security does not scale, and people who still rely on point-and-click approaches struggle to keep up in environments that change daily.

There is a shortage in cybersecurity. But it’s not primarily a shortage of entry-level analysts. It’s a shortage of people who can design systems, engineer controls, and reduce uncertainty at scale. Organizations still desperately need cloud security architects, security engineers who can automate controls, detection engineers who build logic instead of just monitoring alerts, and professionals who understand AI risk, governance, and system-level resilience.

This New Paradigm Rewards Builders and Thinkers

This rewritten cybersecurity playbook doesn’t reward checklist followers. It rewards people who build, explain, adapt, and think in systems.

Cybersecurity is no longer something you simply enter and progress through. It’s something you shape. Whether inside an organisation, alongside AI agents, or independently as a solopreneur, the opportunity is there for those willing to evolve. The rules have changed. The question is whether you’re playing the new game or still following the old one.

Closing….

The old pyramid model is slowly flattening. In the past, this space had a broad base of junior operators handling repetitive tasks, with a narrow top of architects and strategists designing systems. Today, that structure is changing. Organizations are reducing reliance on purely operational roles and increasing expectations that even early-career professionals understand automation, cloud environments, and system design principles, or they simply want to hire more skilled professionals to cover those bases in terms of infrastructure, automation etc.

This shift isn’t a threat, it’s a signal. Artificial Intelligence doesn’t need to outperform you at strategic thinking to change the market. It only needs to perform standardized tasks well enough to make certain entry-level functions less valuable. The impact isn’t a dramatic collapse though; it will be a more gradual role compression.

To the early-career professionals reading, this is not a reason to panic. It is a reason to reposition, re evaluate your goals and factor these things and go get them!!. Future-proofing your career now means moving beyond task execution. It means learning to design systems, automate workflows, think in architecture, and understand how cloud-native environments operate. The goal is to work at a level where AI becomes a tool you leverage and design around not something you quietly compete with for the same checklist-driven responsibilities.

That’s the real reset happening in cybersecurity and the sooner you recognize it, the sooner you regain control over your trajectory instead of reacting to it. Shalom!!!