An Associate, Information Security Officer who rebuilt a fintech’s security posture under active attack and trained over 150 professionals, Janet Njoku explains why certified teams fall short and what hands-on experience builds that no course can.
Regulators are starting to agree. The move away from treating certification as a proxy for capability is no longer just practitioner frustration; it is showing up in policy. ISC2’s 2025 Workforce Study found that 95% of organizations report skills gaps, and the two areas flagged as most critical, cloud security and GRC, are precisely where surface-level training tends to break down fastest. The constraint isn’t bodies. Its depth.
To get specific about what depth requires, we spoke with Janet Njoku, Associate, Information Security Officer (GRC) at Multigate Payment Limited in Lagos, Nigeria. She entered technology without institutional access or formal training, teaching herself how networks, hardware, and software operate from a mobile phone. That foundation led her to cybersecurity, and to a conviction that has shaped everything since: you cannot secure what you don’t understand at the system level. She went on to lead security transformations at a fintech that was under active attack, where the work wasn’t theoretical. She also built a training program designed around the gap between what certifications test and what production environments actually demand. Today, she operates across the full regulatory complexity of her sector, where PCI DSS, ISO 27001, GDPR, and Nigeria’s NDPR don’t apply sequentially. They apply all at once.
Janet, the global cybersecurity workforce gap is routinely framed as a numbers problem: not enough certified professionals. You’ve worked inside organizations that had credentialed staff, documented processes, and functioning security teams, and still experienced repeated breaches. What does the industry keep getting backwards?
Certifications tell you that someone passed a test in a controlled environment. They don’t tell you how someone handles things when everything’s on fire, and the screen looks nothing like the playbook. The companies I’ve seen really struggle aren’t even understaffed. They have plenty of credentialed people. The problem is they don’t have engineers who can actually read their environment, who’ve been around their systems long enough to feel when something’s not right, before the alerts even go off. That gut instinct doesn’t come from a course. It comes from being in the trenches, making real mistakes that actually cost you something, and figuring out what went wrong.
You built your technical foundation on a mobile phone, without a degree, without institutional access, and without a lab. Most people in that position never make it into enterprise security roles. What did that unconventional foundation give you that a traditional path might not have?
It gave me the habit of figuring things out from first principles. When you don’t have a structured curriculum telling you what to learn next, you have to understand why something works before you can move forward. I couldn’t just memorize a concept and pass a module. I had to actually make it work on the device in front of me. That changes how you think. When I got into production environments later, I wasn’t looking for a procedure to follow. I was reading the system. I think that instinct comes directly from having learned that way.
You joined Multigate Payment Limited, a fintech company that had been experiencing repeated cyberattacks, and led a comprehensive transformation of its security posture, including cloud audits, penetration testing, and vulnerability remediation. What did you find when you first mapped the environment, and what did the actual work of rebuilding the security posture involve?
The first thing I did was map the environment as it actually existed, not as it was documented. And there’s almost always a gap between those two things. The cloud audit turned up exposures that had been sitting there long enough that nobody was questioning them anymore. Misconfigured access controls. Overprivileged identities. Logging gaps that made entire categories of activity invisible. Penetration testing on the core product found critical vulnerabilities in the application layer, things that an external attacker could have reached. The remediation wasn’t dramatic. It was just methodical. You prioritize by exploitability and business impact, work through the critical findings first, rebuild the controls that have drifted, and then set up the monitoring so you catch the next drift before it becomes the next problem. The measure of success for me wasn’t the audit report. It was when the attacks stopped. And when the customers who had lost confidence started coming back.
Most security failures in production environments don’t happen because engineers lack knowledge; they happen because lab conditions don’t replicate real ones. You’ve spoken about experiencing that gap firsthand early in your career, when a live implementation didn’t go as planned. Where does that disconnect show up acutely, and what does closing it actually require?
It shows up the moment something deviates from what the documentation anticipated, which, in a real client environment, happens constantly. What I hadn’t done before that call was a stress test against the variables a real environment actually introduces. When it failed, I stopped trying to fix it in front of the client. I shifted to what I could control, explaining exactly what the solution was designed to do, what problem it solved, and why it was the right answer for their situation. The client’s confidence held. That experience changed how I work. You have to simulate real environments, not just practice in controlled ones. And when a system fails, the engineer who can clearly explain what’s happening is the one the room trusts. Those two things, technical execution and communication under pressure, are not separate. In production, they happen at the same time.
You’re managing PCI DSS, ISO 27001, GDPR, and NDPR simultaneously, four frameworks written for stable infrastructure, applied to infrastructure still being built. Most GRC professionals spend a career on one. What does that combination demand that none of the frameworks prepare you for?
The frameworks tell you what good looks like once you’ve already got a baseline. What they don’t tell you is how to sequence your priorities when you’re building that baseline and operating in production at the same time. And that’s the actual situation most organizations in this region are in. GRC in that context isn’t a checklist exercise; it requires real judgment about which controls are foundational and which ones are just procedural. Because you can’t do everything at once, and the order you do things in matters enormously. The organizations that get this right aren’t necessarily the ones passing every audit. They’re the ones where the team actually understands why the controls exist, not just what they’re required to document.
You’ve trained over 150 people in cybersecurity, built a program around real cloud infrastructure rather than lab simulations, and structured it so that every participant leaves with portfolio evidence they can put in front of a hiring manager. The ISC2 study says cloud security and GRC are the two skills organizations most urgently need. Your program targets exactly that gap. What does it do that every other training on the market doesn’t?
Most training teaches people to understand cybersecurity. Mine is designed to make them capable of doing it, which requires having actually done it, not watching someone else do it in a demonstration environment. The program puts participants inside real cloud infrastructure: they deploy resources, configure them, and then secure them. They encounter the problems that emerge in real deployments, not the sanitized versions in a lab exercise. The projects they build become portfolio evidence they can put in front of a hiring manager. I also offer scholarships in every cohort, because the gap this program is trying to close isn’t only technical, it’s access. If financial resources determine who gets in, the talent pool stays narrow exactly where it needs to grow. What I found consistently in the people I’ve trained is that the gap was never really about concepts. It was confidence, the kind you only get from having worked through something real and come out the other side knowing you can handle it.
Your training program includes scholarships in every cohort, targeting women, young professionals, and underrepresented groups. What drove that decision, and what have you seen it change in practice?
It came from my own experience. I know what it is to want access to something and not have the financial resources to get there. Talent doesn’t distribute itself according to who can afford training. If the entry point to the field is financial, you’re filtering out a portion of the talent pool before it ever gets a chance to demonstrate itself. What I’ve seen in practice is that the scholarship recipients are often among the most committed people in the cohort. They show up with something to prove, and they work accordingly. The field needs that energy. It also needs the perspectives they bring. Cybersecurity built from a narrow talent pool has blind spots. Broadening who gets in isn’t just an equity argument. It’s a capability argument.
You’ve built expertise across cloud security and GRC inside a live payment platform, the exact combination ISC2 identifies as most critically absent globally. From that position, where does the industry’s next critical challenge actually lie?
The industry’s next critical challenge is the shortage of security leaders who can operate at both ends at once, technically and strategically. The credential problem is real, but it’s a symptom. Effective security leadership requires a combination that’s genuinely hard to find: someone technically fluent, who can translate risk into terms executives will act on, and who knows which threats matter right now and which are noise. You can train people on frameworks. You can certify them on tools. What you can’t give them is judgment. My path from technical work through GRC toward leadership wasn’t a career change. It was layers. You can’t secure what you don’t understand, and you can’t lead what you haven’t built.
You’re aiming toward a CISO role within the next two years. You’ve described your path from hands-on technical work through GRC toward leadership as layers, not a career change. What does each of those layers give a security leader that the others can’t replace?
Technical depth gives you credibility with engineers and the ability to recognize when you’re being told what someone wants you to hear versus what’s actually happening. GRC gives you the language to translate risk into something a board will act on. Leadership gives you judgment about people, which is where most security programs ultimately succeed or fail. A CISO who came up only through the technical track struggles with the organizational dimension. One who came up only through compliance loses the room when engineers start talking. Having built both, I feel prepared.
