Articles & Reflections

The 80 Interns I Didn't Have to Train

Every year at the Government of Sharjah, we took in about 10 university interns. Over eight years, that's roughly 80 young professionals who walked into our department with no cybersecurity experience, uncertain career plans, and the nervous energy of someone who doesn't yet know what they're good at.

I didn't have to train them. It wasn't in my job description. I was managing a department of 22, overseeing security operations for 180+ government entities, reporting to the Executive Council, and building a compliance program from scratch. Nobody would have blamed me for handing the interns a reading list and pointing them at a desk in the corner.

I trained them anyway. Personally. Every cohort.

Why

Because someone did it for me once. When I walked into the Indian Institute of Science in 2000 as a research assistant — young, inexperienced, out of my depth — someone took the time to show me how things actually work. Not just the technical skills. The thinking. The discipline. The habit of asking "why" before asking "how." That year shaped the next 25 years of my career.

I never forgot that. And when I had the opportunity to do the same for someone else, I took it seriously.

What Training Actually Looked Like

I didn't run a classroom. I ran an immersion program.

Interns rotated through every function in the department. They sat in the SOC and learned to read alerts — not just what a SIEM displays, but what it means, why it triggered, and what you do about it. They worked on GRC projects and saw how a policy written on paper becomes a control tested in practice. They joined penetration testing engagements and learned that the attacker's perspective is the most valuable perspective in defense. They attended executive briefings and saw how technical risk gets translated into language a board can act on.

I paired every intern with a senior team member, but I also spent time with each one directly. I wanted to understand what they were curious about. What scared them. What clicked. Because the goal wasn't to turn them all into SOC analysts. The goal was to help them discover which part of cybersecurity — if any — fit the way their brain works.

Some of them were technical thinkers. They came alive in the SOC, connecting dots between alerts and building mental models of attack chains. I pointed them toward security operations and threat analysis.

Some of them were systems thinkers. They saw patterns in compliance frameworks, understood how controls map across standards, and liked the challenge of making governance work at scale. I pointed them toward GRC and risk management.

Some of them were communicators. They could take a complex security concept and explain it clearly to someone who knew nothing about technology. I told them that skill was rarer and more valuable than any certification they'd ever earn.

And a few of them discovered that cybersecurity wasn't for them — and that's a perfectly good outcome too. Better to discover that during an internship than three years into a career.

Where They Are Now

Most of those 80 interns have gone on to build careers in cybersecurity. Security operations. Governance and compliance. Risk consulting. A few are in leadership roles now. Several have reached out over the years to tell me that their time with us was the turning point — the experience that convinced them to commit to this field.

I don't take credit for their careers. They built those themselves. What I take credit for is creating an environment where they could discover what they were capable of. Where they were trusted with real work, not busywork. Where they were treated as future professionals, not free labor.

What This Taught Me About Leadership

Training interns taught me more about leadership than managing a department of 22 ever did. Here's why:

When you manage experienced professionals, you can rely on shared context. You say "run a gap analysis" and they know what that means. When you train an intern, you have no shared context. You have to explain not just what to do, but why it matters, how it connects to everything else, and what good looks like versus what bad looks like. You have to make the implicit explicit.

That discipline — making the implicit explicit — made me a better manager, a better communicator, and a better leader. If you can explain cybersecurity governance to a 21-year-old university student in a way that makes them care about it, you can explain it to a board of directors. The skill is the same.

The programs I built will eventually be replaced. The tools I deployed will eventually be retired. But the people I trained are still out there, building security programs of their own. That's the impact that compounds.

A Note to Leaders Who Think They're Too Busy

You're not. I trained interns while building a cybersecurity function from zero, scaling a team from 3 to 22, managing a 24/7 SOC, running a state-wide compliance program, and reporting to an executive council. If I had time, you have time.

The return on investment is not immediate. You won't see it in your quarterly metrics. You'll see it five years later when someone you trained sends you a message saying "I'm a security manager now, and I still use what you taught me." That message will be worth more than any KPI you've ever hit.

Invest in people. It's the only thing in this industry that doesn't depreciate.

Every Framework Is the Same Framework. That's Why I Can Implement Any of Them.

NIST CSF. ISO 27001. COBIT. HIPAA. SOX. PCI DSS. CCPA. FedRAMP. CMMC. SOC 2.

I've implemented most of these. Some multiple times, across different organizations, in different industries, in different countries. And the single most useful thing I can tell someone early in their GRC career is this: they are all the same framework wearing different clothes.

Every compliance framework in existence follows the same fundamental structure:

1. Scope it. Define what you're protecting, who's responsible, and what's in and out of bounds.
2. Assess the gaps. Compare what you have against what the framework requires. Be honest.
3. Map controls. For every gap, define what control addresses it. For overlapping frameworks, map controls once and apply them across standards.
4. Remediate. Fix the gaps. Prioritize by risk, not by how easy they are to check off.
5. Monitor. Continuously verify that controls are working. Not annually. Continuously.
6. Report. Translate technical compliance data into language your stakeholders understand.
7. Repeat. Compliance is not a project. It's an operating model.

The specific domains change. HIPAA cares about protected health information. PCI DSS cares about cardholder data. FedRAMP cares about federal information systems. But the implementation methodology — the actual work of getting an organization from non-compliant to compliant — is structurally identical.

This is why experienced GRC professionals can move across frameworks and industries without starting from scratch. It's not that we've memorized every control in every standard. It's that we understand the pattern.

When a client or employer tells me they need to comply with a framework I haven't worked with before, I don't panic. I ask for the standard, spend a few days reading it, map it against what I already know, and deliver a plan. The plan always looks the same. Because the work always is the same.

Six years of consulting across 10+ organizations taught me this. It's the most transferable skill I have.

I Built 3 Applications With AI. Here's What Every Security Leader Should Know.

I'm not a software engineer. I'm a cybersecurity professional with 15 years of experience in GRC, security operations, and architecture. In early 2025, I started building production-ready applications using AI-assisted development tools. Here's why, what happened, and what it means for security leaders.

Why I Did It

For 15 years, I've been on the receiving end of technology. Evaluating SIEM platforms. Procuring GRC tools. Writing requirements for engineering teams. Reviewing architecture diagrams I didn't fully understand. I was effective at my job, but I had a gap: I'd never built anything myself.

When AI development tools like Claude Code reached a point where a non-developer could build real applications — not toys, not prototypes, but production-ready software — I decided to close that gap.

What I Built

Three applications. The flagship is a full-stack GRC platform: multi-tenant architecture, AI-assisted risk scoring, compliance framework mapping (SOC 2, ISO 27001, HIPAA, NIST CSF), automated vendor assessment workflows, and role-based access control. Built with Next.js, TypeScript, PostgreSQL, Prisma, Docker, and LLM integration. Deployed to Akamai cloud from the command line.

What I Learned About the Technology

AI-assisted development doesn't mean AI does the work. I still had to understand what I was building. I made the architecture decisions. I designed the data models. I chose the frameworks. I debugged the issues. The AI accelerated the coding — turning my decisions into working code faster than I could have written it manually. But the decisions were mine.

This is important because it means AI development tools are most powerful in the hands of people who understand the problem domain. I know what a GRC platform should do because I've used, evaluated, and managed them for 15 years. The AI helped me build it. But the AI didn't know what to build. I did.

What I Learned About Myself

Building software changed how I approach security work. In architecture reviews, I now ask different questions — questions about data model design, API security patterns, and deployment configurations that I previously would have deferred to the engineering team.

What This Means for Security Leaders

I'm not suggesting every CISO should learn to code. I'm suggesting that the security leaders who will be most effective in the next decade are the ones who close the gap between security strategy and technical implementation. AI tools make that possible in a way it wasn't before.

You don't need to become an engineer. You need to build one thing. That experience will change how you think about everything else in security.

From 3 to 22: What I Actually Learned About Building a Security Team

Over eight years at the Government of Sharjah, I scaled a cybersecurity team from 3 people to 22. Here's what that actually looked like — and what I learned that no management book taught me.

The First Three Were the Hardest

When there are only three of you, everyone does everything. There are no specialists. You're writing the incident response playbook and you're also the person who responds to the incidents. You're designing the security architecture and you're also the one configuring the firewall rules.

The hardest part of this phase isn't the workload. It's the discipline to document what you're doing while you're doing it. When you're moving fast with a small team, documentation feels like overhead. But if you don't document, you can't scale.

Hiring Is Not About Resumes

The best hire I ever made didn't have the strongest resume. What they had was an instinct for ownership. When something broke, they fixed it — before anyone asked them to. When they noticed a gap in our process, they drafted a proposal to address it.

The worst hire had excellent certifications, impressive previous titles, and a fundamental expectation that someone else would tell them what to do every morning.

After that experience, my interview process changed. I stopped asking "tell me about your experience with [technology]" and started asking "tell me about a time you noticed something broken and fixed it without being asked."

Mentoring Is the Job, Not a Side Activity

At 22 people, I wasn't doing security work anymore. I was building the environment where other people could do security work well. That's a fundamentally different job, and not everyone makes the transition successfully.

Culture Eats Process

You can have perfect runbooks and still have a dysfunctional team. You can have imperfect runbooks and still have a team that performs. The difference is culture.

The culture I built — and the culture I look for — comes down to three things:

• Ownership: If you see a problem, it's your problem. Even if it's outside your job description.
• Honesty: If something isn't working, say so. No one gets in trouble for raising a problem.
• Respect: Every person on the team is treated as someone whose perspective matters.

That culture is why we maintained zero audit failures for eight years. Not because our controls were perfect. Because when something wasn't working, someone said so, and we fixed it.

The Consultant's Mindset: Why I Listen Before I Solve

I spent six years as a cybersecurity consultant, working with 10+ organizations across government, banking, and enterprise. The most important thing I learned had nothing to do with cybersecurity.

It's this: the person hiring you usually knows what's wrong. They just can't articulate it yet. Or they can articulate it, but they're describing symptoms, not the root cause. Your job isn't to show up with answers. Your job is to ask the right questions until the real problem reveals itself.

The Template Mistake

My first consulting engagement was at a bank in Dubai. I walked in with a gap analysis template I thought was comprehensive. Sixty questions. Every ISO 27001 control domain covered. Three days into interviews, I realized my template was useless — not because the questions were wrong, but because the client's organization didn't work the way my template assumed.

I threw the template out and started over. Instead of asking structured questions, I asked one open-ended question to each department head: "Walk me through how things actually work here."

What I heard was completely different from what the project brief described. The brief said the problem was "lack of ISMS documentation." The actual problem was that three departments had overlapping responsibilities, no one had clear ownership of key processes, and the policies that did exist contradicted each other.

The Discipline of Listening

After that engagement, I built a personal rule: the first 20% of any engagement is listening. Not presenting. Not assessing. Not recommending. Listening.

This discipline is uncomfortable because clients are paying you to deliver, and listening feels like not delivering. But it's the single highest-value activity in any consulting engagement.

The consultants who fail are the ones who show up on Monday with a slide deck full of recommendations. The consultants who succeed are the ones who show up on Monday with a notebook full of questions.

I'm Not Looking for a Title. Here's What I'm Looking For Instead.

I've led a 22-person security department. I've reported to executive councils. I've earned industry awards. And right now, I'd be equally happy working as a SOC analyst, a GRC lead, a security architect, a project manager, or a CISO.

That's not desperation. It's a deliberate choice.

The Title Trap

I've seen what happens when people optimize for titles instead of impact. They take the VP role at a company where the VP has no budget, no team, and no executive support. They take the Director title at a company where the Director reports to someone who doesn't understand security. They get the title and then spend two years frustrated because the title didn't come with the ability to actually do the work.

I'd rather be a Senior Analyst at an organization where I can make a real difference than a VP at an organization where I'm fighting for basic resources.

What I Actually Optimize For

• The problem: Is there a meaningful security challenge to solve? Building from scratch, fixing something broken, scaling something that's working — all of these excite me.
• The team: Are the people I'd be working with good at what they do and invested in the outcome?
• The mandate: Does leadership actually want security to succeed, or is this a checkbox?
• The autonomy: Can I make decisions and execute, or am I going to spend 80% of my time in approval chains?

The Flexibility Is a Feature

I've been the executive in the boardroom and the IC on the floor. I've written the strategy and I've also written the SIEM use cases. I've managed a $2.3M budget and I've also manually configured firewall rules.

Most people at my experience level have narrowed into one lane. I haven't, and I don't want to. Because the reality is: the best security professionals I've ever worked with are the ones who can operate at multiple altitudes.

I'm one of those people. If that's what your organization needs, let's talk.