I believed certifications mattered. Hell, I even got short-listed for the EC-Council Canada Hall of Fame and made YouTube videos promoting this stuff.

I got my CEH and I'm glad I did because building that home lab, staying up late figuring out how things broke, sharing war stories with other wannabe hackers. That part was genuinely valuable because it lit the spark.

But here's the uncomfortable truth someone needs to say, and I'd rather it come from someone who's been exactly where you are rather than you discovering this fact 8 months into your rejection journey.

The Marketing Bullshit

No, Security+ and Google Cybersecurity Certificate are not enough to land an entry-level role in the current market. Stop asking.

The entire certification industry is marketing on false premises. They keep pushing the narrative that there are "millions of unfilled cyber jobs," but that's straight-up deception built on the assumption that exponential growth from my era would continue forever. Spoiler alert: it didn't.

I started in 2015, when companies were literally plucking students off campus in their first year of university. I signed a full-time job in second year and only finished my degree because I wanted to, not because I had to. That world doesn't exist anymore.

Back then, it was Target, Yahoo, Ashley Madison breaches. Later, Equifax. Companies were moving to the cloud, building massive security teams that were finally breaking away from infrastructure and IT to become their own thing. You'd have auditors discovering Windows NT systems with LM hashes that a red team could crack in minutes.

Now the industry has matured. The problems are "higher hanging fruits" requiring more seniors: cloud security, AppSec, GRC engineering. The market has bifurcated completely: senior roles are safe with increasing demand, but entry-level is brutal.

My story is a success story from a different time. Problem is, everybody assumed this trend would continue forever. Every school in my province now has a cybersecurity degree! In 2015, there were none. Security wasn't even cool! All computer sciences students wanted to do were AI, videogames and mobile.

We get 500+ applicants for a single intermediate role. Do you like those odds?

The Certification Bodies Didn't Keep Up

Here's what happened while everyone was getting sold the "cybersecurity gold rush" story: the certification curriculum stayed idle.

Certifications like CEH and Security+ still focus on foundational skills (think Kali Linux, Windows environments, switches and networks). But the real world has moved on. Today, the "foundations" should be Kubernetes security, cloud IAM, supply chain risks and AI governance on top of the existing ones. The bar needs to rise!

Everyone's doing the same path: YouTube/Udemy → Google Cyber → CompTIA → TryHackMe → Splunk. Then Tenable → CrowdStrike → ELK. It's hard to differentiate when everyone's following the same playbook, and certification bodies haven't caught up. They're still operating like it's 2015, including the curriculum.

Those vocational curriculums sound like a good start, but they won't get you hired in security right off the bat. They're the bare minimum, like someone doing their own taxes thinking that qualifies them to be a corporate accountant.

You're now competing with hundreds of thousands of people who were told the exact same thing about security being the path of the future. The bottom of the market is completely saturated with identical applicants who all have Security+, Google Cybersecurity, and some general IT knowledge. Demand is crushing supply. I call this "the slush pile".

What Actually Works (And What I Did)

You need to acquire the skills, meet people, get noticed. I did this too.

I landed an internship with a paper resume at a career fair simply because I was fascinated by "access management of documents" and, yes, Mr. Robot. Yes, it was an easier market. Still, my strategy was still better than the "spray and pray" applications I see most of you using. I had attended a "Lunch and Learn" event on campus where a security analyst spoke about transitioning careers while raising toddlers (I had 2 myself at the time). I emailed him afterwards, visited the company premises weeks later, and spoke with a dozen people about the job. Four months later, when I applied for that internship, they remembered me. That's what I mean by "getting yourself out there"!

Your best bet at pivoting is becoming the job you want from within your current role. If you're currently employed, you have a much better shot at pivoting by actually speaking with people. What good is it if you just do a bunch of certs in your corner?

Make friends with the compliance team! Show how what you do enables compliance, how your work helps secure systems. Join the security champions program. Get noticed, and you'll get actual experts speaking with you. You'll learn much better talking with people than rummaging through textbooks.

Don't ask for mentorship. Ask for people's opinions on something you both care about. "Will you mentor me?" is like asking "Will you be my friend?" to a stranger.

We Need to Stop the Certification Narrative

We need to stop the "school narrative," wherein you acquire a credential and that credential "unlocks a new level" (a job). I'm seeing people plot their pathway to CISO, one certification at a time. That doesn't work like that!

Certifications teach you how to pass a multiple-choice exam. We need to stop pretending you can multiple-choice your way to companies' current problems.

Here's what works: you need to provide value for people to find you interesting. Stop thinking about HTB boxes and start thinking about inefficiencies in triaging techniques. Think about that PowerShell script you're running to get Azure events: make it compute faster while avoiding API rate limits. THM is fine, but how many times do you run Bloodhound in day-to-day work versus finding a better way to document false positives?

Your manager needs efficient workers more than HTB champions.

The Uncomfortable Truth

I'm letting my CEH expire this year. I'm done. After close to a decade in this field, I've learned something painful: the certification treadmill doesn't take you where you think it's going. The "certification industry" needs to stop selling fantasies to entry and intermediate level people.

Getting into cyber nowadays means you have to be in it because this is what you want to do and can't imagine doing anything else. There's been huge marketing about cyber being an easy path toward six-figure salaries, but this is deceptive and objectively wrong. This isn't the convenient career path anymore.

In my city we need construction workers, nurses, and teachers. I imagine it's the same everywhere. These are the current easy-to-get jobs.

I'm grateful for my CEH because it got me started, but I've outgrown it, and so has the industry. The reality is harsh: no certification body is keeping up with the pace of change.

The careers are still being built. Just not the way the certification industry wants you to believe. And definitely not the way I used to promote in those YouTube videos.

Now that you know my story, what's yours going to be?

And I get it, most business devs suck at their job. They have a 'takers' mentality: they have their battlecards and go through their motion and you see right through them. But that's not a reason to dismiss the industry.

At first, I thought it was a form of humblebrag. Confession time: I joined LinkedIn precisely because my colleagues were bitching about having so many recruiters "annoying" them and thought I deserved a piece of the action. All this to say: what you see as an annoyance can be someone else's desire, so be careful throwing them down.

But this gets deeper. I think the aversion to the industry is deeply rooted in our discipline... and I think it's a problem.

The Hacker Myth

There’s a prevailing mindset in this field that "real" teams build their own tools. This mentality comes from our hacker roots. A hacker tinkers, customizes and cleverly tweaks. For many of us, building is part of our identity. It’s what we’ve done for years. It’s what made us fall in love with the technology in the first place.

I admire that hacker mindset. The curiosity. The initiative. The sense of being able to outsmart the system. But inside an enterprise environment, that instinct often requires a shift toward what might seem like the "boring" choice: corporate bowties and croissants conferences.

Build vs Buy is one of my biggest ongoing debates with my colleagues, and I'd argue, in the GRC industry as a whole. I'm part of the latter group: let's rely on this company who lives and breathes a single problem to solve our identical problem. Developers cost hugely and they hate doing maintenance. A McKinsey study found that developers spend up to 50% of their time on maintenance rather than innovation.

The counter-argument I keep hearing is about how these security tools cannot meet our needs. I counteract with: How unique are you, really? And should you be that unique?

In most cases, the extra 10% of customization we’re craving comes with a hidden cost. Think time spent on maintenance, troubleshooting, documentation, and support. WHICH EVERYBODY HATES TO DO. Internal tools lack the external support you get from vendors. You lose the ability to escalate when things go wrong, and you’re left managing a tool that can easily become a liability if the original builder leaves or moves on. In fact, Forrester points out that 70% of orgs struggle with knowledge loss when technical staff leave teams that maintain custom tools.

At a certain scale, building becomes a trade-off that limits our ability to focus on the real, high-value problems that only we can solve.

What about GRC?

Now, as a GRC professional, it’s easier for me to advocate for buying instead of building. My job is to make strategic decisions, not to write code. But that’s not just a fallback option. I believe my bias is based on the reality of operational efficiency. Buying a tool doesn’t mean you’re less technical or that you’re not capable of building. It means you’re choosing to focus your time and energy on doing something else than debugging software (a.k.a not bringing security value). It’s a decision to invest in scalability and sustainability rather than novelty. A vendor’s tool is already tested, supported, and maintained. Let them update those hosts and containers.

The relationship with a vendor also gives you leverage. You can push them for improvements, tie renewals to their roadmap, and hold them accountable. That’s harder to do with in-house tools, where you’re locked into whatever you've built, often with no clear escalation path when things go wrong. Worse, from what I've seen, sentiment gets in the way. It kind of get difficult to tell Larry that his software sucks if you ride in the same bus every day.

The Cost of Humans

Hiring people to build things can be a great solution too, but that takes more discipline. It’s not about pushing a few buttons or making a quick change. It’s about coaching, upskilling, and managing. You’re not just paying for a tool, you’re investing in people who will need your guidance, mentorship, and time to grow. That takes a lot of effort, especially when they are managing tools that don’t have external support.

None of this is to say that building tools is inherently bad or unnecessary. Sometimes it’s exactly the right decision. But too often, the drive to build is fueled by an identity, a culture of hackerism that places more value on being different than on being effective. The truth is, most enterprises don’t need to reinvent the wheel.

In a high-functioning enterprise, the real work often looks like buying the “boring” tool even if it makes you feel like a corporate stooge or a sellout. But boring gets things done. And let’s not forget the CFO. Predictable OpEx beats mystery Dev time. Buying lets you forecast, track ROI, and tie spend to value. And in security, that’s the kind of work that really matters.

I wrote a similar article in reaction to my visit at the "North Sec" a passion-driven conference:

We can’t build the cybersecurity workforce on passion alone

Envisioning the transition of cybersecurity from a passion and skill-driven activity to a casual business profession.

ppfosecPierre-Paul Ferland

Don't worry. I'm not about to spend the next 1,000 words of your time telling you about how great I am. I'm still figuring this out. Think of it like an ideal to reach.

What I do know, as someone with some experience, is that there’s a moment in every GRC career when you realize: this job isn’t really about controls or policies. It's about understanding the people making decisions, often without us, most of the time with good intentions, but with poor incentives. And it’s easy to feel like the work is being done without us, or worse, that it’s happening in spite of us. This is how most of the frustration in GRC builds up. Worse, you expect change, but the changes accelerate, just not on the parameters you need them to change!

I had this realization pretty early in my career. I was part of a team that thought it had a duty to be the "conscience" of the company and to "mature" it. The idea was to build such compelling risk stories that some careless projects would slow down. But the reality was that no one listened. The more I pushed, the more isolated we became. Team meetings were basically just ruminations on how these guys were driving the company into a wall.

This brings me to another hot topic: security is not cool. We will never push a feature that makes people lives measurably better. We will never single-handedly enthrall an audience with our demo skills. So, imagine: a bunch of specialists worried about being right while the "others" were getting featured internally. After a bunch of burnout and resignations, the lesson was clear: being right doesn’t matter if no one listens.

That's why I insist on relevance. Making security work isn't about authority (we don't have any) or following the frameworks (they're vague and full of holes). It's about being curious about systems, asking questions that no one else thinks of (because we do have a different, adversarial, perspective), and listening more than telling. There's a saying: "greatness is in the agency of others". So, what makes a GRC specialist "great"? How about ensuring others are allowed to build great things?

GRC Is Not a Role. It’s a Practice.

What makes GRC impactful isn’t just ticking off items from a compliance checklist. GRC is a practice that requires understanding the full scope of a business. I'd argue, this is even the most interesting aspect of security, the one I always use when people ask me why I love this practice! It’s not enough to know the framework or the policy; you need to understand how things really work in the business, from all layers: products, sales, infrastructure, applications, databases, networks, processes, legal, hiring, firing... you touch everything, might as well be curious about everything!

I can’t tell you how many times I’ve been in a meeting where I could connect two people or two systems to help with an issue that had no relation with security. There's this inside joke in networking: "The problem is always DNS!" Funny thing: most software developers don't know that meme, so when you debug them by finding that DNS flaw: that's "street cred"! This amount of cred is your capital. With this sympathy, you earn trust. By virtue of you being connected to every "system" (human of software or business, think systems-thinking), you see patterns that specialists won't see.

This is how you become uniquely positioned in your practice: your constant drive to learn about everything helps people learn more themselves, making everyone richer. As my philosophy teacher said in college: "Knowledge is the only thing you can give someone without having less for yourself". This is why "practice" is so deliberate: a practice has a predisposition on learning, because it evolves.

Relevance, Built Slowly

When you’re doing this work right, most of what you influence will be invisible. Back to my "you're not cool" point: You won’t be recognized for the risks that didn’t materialize, the issues you avoided, or the changes you made quietly behind the scenes. It's impossible to prove the absence of something, and we have no control group to validate what would happen if we did nothing. Ironically, the most praise I've seen a security team get is when we finally remove security measures that had terrible UX. That VPN product that took forever to connect. That inefficient password rotation...

Anyway, the real impact of GRC isn’t in the loud moments. It’s in the invisible work. The subtle nudges you make to help a team shift their thinking. The quiet check-ins to make sure people are aware of your services. The decision to gently remind a product team that there’s a better, safer way to approach a problem without slowing them down.

We tweak permissions. We notice weird contractual clauses that we get deleted. We convince VPs to pay the SSO tax. We see an alert in our configuration management systems and get a user removed. We screen consultants. Yes, sometimes we need to bust out the “policy says” approach. But most of the time, going in humble and curious, you can ask the right questions to get to the why your perspective matters. "You want to use this database? Ok, I'm wondering how will you manage the data residency?". I've asked that, knowing that the database in question didn't support that. I could have said "forget it, data residency won't work". But that feels like your parent telling you what to do. It was invisible work, but that’s the job. And it was only possible because I’d built the trust to have those quiet, important conversations.

In GRC, trust is earned slowly by being present and consistently showing up without needing to be recognized.

The Hardest Part: Sitting with Ambiguity

The real growth in GRC comes from sitting with the ambiguity. This job is not about certainty or easy answers. There are moments when you don’t know if a decision is going to be the right one, and you have to be comfortable with that. In fact, that can become your superpower. Executives, in my experience, dislike when we throw ambiguity back at them.

We can never know when an attack will happen and on which entry point. All we do is relying on educated guesses, intuition, and hopefully some data to steer our decisions. Yet, we must never walk into a meeting with a blank slate. As GRC specialists, our value lies in how well we articulate the problems, solutions, tradeoffs. When someone brings up a vendor, we can’t afford to give soft, evasive opinions. “We’ll have to do a risk assessment” isn’t enough. We need to have a take. We need to know when a vendor is a ticking time bomb and when a risk is just noise.

No, we can’t predict exactly when a third party will get breached. But we can absolutely call out when a vendor sucks at security. And we can design guardrails that limit the blast radius when things go wrong. That’s our job. That’s what earns us a seat at the table. Clear, assertive guidance in the face of limited data, while not going into full bullshitter mode, is the line we thread.

If we own the ambiguity, we abstract the complexity. That’s how things actually move forward. That’s the difference between being a GRC advisor who shapes decisions, and being a “meeting facilitator” who just nods along and documents action items no one reads.

You don’t win influence with risk methodologies. You don’t win it with strategic alignment decks or quoting frameworks. Most of that is corporate filler. You win it by being useful, direct, and present. By understanding what’s at stake, what matters to the business, and how to move toward safer decisions without slowing people down.

That’s what I look for in great GRC work.

It’s in whether people want you in the room before the decision is made.
That has everything to do with how you show up.

For a long time, I thought influence came from structure and efficiency. If we build the right model, the right RACI, the right ticketing flow, the right automation, things would click. But structure doesn’t build trust. Presence does.

Presence is being there when the vendor is picked (not after the contract is signed).
Presence is being looped into a design document of the first draft of a new system.
Presence is saying, “Let me help you do this right,” before anyone even asks.

And I know how idealistic that sounds. GRC teams are stretched thin. We’re not always invited. We’re often chasing after projects already underway. I'm pretty sure I'm being overlooked in many projects despite everything that I do. But that’s the work. That’s the price to stop being the team of “no” and become the team that helps everyone move forward without stumbling.

Frameworks Are Not Strategy

I’ve written before about how we inherited too much of the checkbox mindset. We were taught that policies equal security. That evidence equals assurance. That frameworks are the work. But they’re not.

They’re sheet music.

They’re useful only if they help us understand the melody of the business. You can read sheet music but that's pretty boring unless you can play an instrument. The real work (a.k.a. playing that violin) is understanding how this company actually builds, ships, sells, and survives and helping it do that more securely.

That’s the difference between GRC as audit prep and GRC as business enablement. One is reactive. The other is embedded. I don't have a sheet music analogy to punctuate that.

When you stop leading with frameworks and start asking what people are trying to achieve, you start seeing the gaps differently. You’re not looking for non-compliance, your mind becomes solution-oriented (solution as in: software solution). This doesn’t mean you throw out compliance. It means you stop confusing it with action.

Relevance Is Built, Not Granted

I think a lot about how trust is built in hallway conversations or in the Slack thread where you helped someone unblock a process instead of quoting policy. Or in the architecture meeting where you asked a thoughtful question and didn’t talk over anyone. That kind of credibility compounds. Quietly. Then suddenly.

And it changes everything.

You stop being the person who files JIRA tickets after the fact. You become the person who gets pulled in before the build.

If you’re in GRC right now and you feel invisible, I see you (get it?). Sometimes, I still do, despite all my speeches about relevant GRC.

But I’ll say this: relevance is the ability to help people find the right ideas or information at the right time for the right need. Can you provide that, or are you simply shifting them your framework?

Try this: map the system down. On a whiteboard or piece of paper. Get a layer where you understand the business intent (this is how we sell this thing), the use case (this is how a human will use the software and get an experience out of it), THEN the tech. Gives you a multi-dimensional mind map of the whole forces at play. That's how I define relevance. If you see these patterns, you can act swiftly.

That’s how you become the advisor, not the afterthought.

My hot take: we are just rebranding the same security principles with shiny new buzzwords. AI systems remain hosted on an infrastructure governed by the same access management, data lifecycle and development principles as any other applications. But that doesn't mean that our discipline won't change. In fact, we're about to get rid of most of the drudgery to finally realize GRC as an advisory function. Let's dig into what's really changing and what remains foundational as we all try to make sense out of this.

The Transformation of GRC in the AI Era

Cross mappings, gap analysis, data classification, controls maturity assessments, policy writing, audits, reviews, procedures writing, guidelines drafting... all of these tasks will soon be outsourced to AI.

I've met CEOs and founders who are using AI to automate entire Third Party Risk Management processes. Think you can catch faster than an AI whenever your suppliers add some shady language in their privacy policy? This is the world that's coming... and it's amazing. The days of reactive, checkbox-driven GRC are numbered.

Picture this: AI agents reading our policies, monitoring risks in real time, embedding security standards directly into coding copilots or agents. The script is flipping. Where we were once primarily information gatherers, we're now becoming curators. AI will have all the answers but it won't be able to ask the right questions.

The routine boring stuff is GONE. No more Excel hell cross-mappings. No more manual risk reports. No more pointless questionnaires. No more bridge letters nobody reads. Only the work that actually matters remains.

AI will handle the vendor due diligence grind. Good. But vendor risk isn't just about filling out a questionnaire. It's about trust. About navigating the human dynamics AI doesn't understand through the whole lifecycle.

Autonomous compliance sounds nice until an LLM hallucinates your security policies into oblivion. We'll need to watch the watchers. Make sure AI isn't just fast but right.

The Human Element in an AI-Powered GRC World

AI can crunch data, but it won't change how people think. Security awareness, culture, leadership are going to become our bread and butter.

A well-trained AI can spot anomalies. A well-trained human can make people care.

AI will still struggle with coordinating cross-functional teams with competing priorities. AI doesn't work well with the messy, unpredictable (by the way, this is why executive assistants' jobs are and will remain safe: too much chaos to deal with). Its decision-making will remain limited. AI will never replace a salesperson or a teacher, no matter how advanced it gets. Humans will always prefer human relationships; purchasing or learning are emotional decisions at their core.

The reality is that no security team can maintain all the information systems in an organization. The only solution is to ensure that the teams that operate these systems consider security. There's no AI prompt for "Should we launch this product despite the security risks?" You need judgment. Experience. Conviction.

The challenge in security has always been about balancing incentives. The carrot approach of praising good behaviors and hyping small successes often struggles to maintain engagement. The stick approach is worse. Try slowing down a development team's sprint to address vulnerability SLAs and see how that goes over.

What remains is the risk-based approach and a great deal of opportunism. The most effective security changes happen when you're involved at the right moment with the right stakeholders. AI might help identify these moments, but it won't replace the human judgment needed to navigate them.

The Reality Check: Same Game, New Tools

When cloud computing arrived, we genuinely had to rethink EVERYTHING. The "network perimeter" became old fashioned. Shared responsibility models emerged. Infrastructure became code. Cloud facilitated containers, kubernetes, serverless...

But AI? Right now, AI remains essentially SOFTWARE running in the cloud processing larger datasets with non-deterministic outputs. It feels like magic but there's nothing magical about how it runs under the hood.

Every builder is embedding models into their products. Soon ALL software will have AI components. Yet somehow we're supposed to believe this requires a completely new security discipline? What will your "AI risk register" look like when every app you use has AI components? The distinction won't matter!

We need less of:

• Expensive "AI security" certifications
• Consultants selling fear of "novel threats"
• Rebranded "AI questionnaires" with security content

And focus on the same challenges:

• Access control
• Data protection
• Supply chain security
• Third-party risk management

Let's face it: "training data poisoning" may be cool sounding but threat actors will still be breaching us with the same tired methods they've been using for 20 years: misplaced credentials, misconfigurations, old vulnerable components, phishing...

While everyone rushes to become an "AI risk management expert," the fundamentals of good governance haven't changed. Your existing frameworks likely already address most of what you need.

The question isn't if AI will change GRC. It's how we'll lead it. I believe the answer lies in the same human-centered approach that has always defined effective security work. AI will enable us to focus more on what truly matters: understanding context, making judgment calls that algorithms can't, and ultimately creating a security culture that's engaging.

Security and compliance will always be human problems at their core. The technology is just a tool. As we move forward, let's remember that our greatest value isn't in what we can automate, it's in what we can humanize (ok that was cheesy).

If you're a TPRM professional who spends your days pushing Excel questionnaires and chasing vendors for "proper documentation", and "remediation" after applying a filter on the "No" questions (or perhaps you're playing chess with the vendor and some questions are formulated negatively, so "No" is the right answer, and you've got a macro doing the filtering!) this is your wake-up call. What you're doing isn't security. You're taking part in compliance theater.

And deep down, you already know it.

The Great Security Questionnaire Scam

Every day, thousands of security questionnaires fly across the internet like digital confetti. 300+ questions of mind-numbing minutiae, desperately trying to cram modern security practices into frameworks designed when client-server was cutting edge.

Here's the ugly truth about this process:

• Vendors constantly make liberal interpretations of the questions in order to check "YES" because they want the sale;
• Customers demand perfection on controls they themselves haven't implemented;
• Everyone involved knows it's theater, but nobody's brave enough to say it;
• The entire process creates precisely zero actual security

Meanwhile, actual business value gets strangled while people argue about whether a managed Kubernetes service meets the definition of "proper network segmentation."

The Questionnaire Time Capsule: Still Asking About Server Rooms in 2025

Your template was probably written by consultants who haven't touched actual technology in a decade. That's why it's still asking questions like:

• "Do you enforce password rotation every 90 days?" while vendors are using hardware keys and biometrics with no passwords to rotate
• "Describe your off-site backup process" to companies using active-active, multi-availability redundant data centers
• "Detail your network segmentation" to teams running service meshes
• "Outline your patch management schedule" to organizations using ephemeral infrastructure that redeploys automatically
• "How do you secure remote access?" when they've implemented device certificates with continuous verification
• "Describe your change approval board process" to teams shipping 1,000 microservice releases weekly with automated testing and instant rollbacks

But instead of acknowledging this disconnect, we've created an entire ecosystem designed to perpetuate the lie. Vendors can't educate hundreds of customers on why these questions are irrelevant, so they just say "YES" and move on. Security teams can't admit their templates are outdated without feeling like they're compromising, so they keep demanding compliance with frameworks designed for a bygone era.

"Security Parent Syndrome"

There are two parallel universes in B2B security. In one, providers build modern cloud infrastructure with zero-trust architectures, automated security controls, and continuous deployment. In the other, customers' security requirements still mandate physical audits of server rooms.

The fastest way to burn out a security professional? Force them to live at the intersection of these worlds.

This "Security Parent Syndrome" manifests in requirements that would be comical if they weren't so crippling:

• On-site security audits for cloud providers ("Just let me schedule that physical audit with AWS real quick...")
• Full background checks for every employee ("Because clearly, our video producer is the weak link in our zero-trust architecture")
• Source code escrow for microservices ("Let me just package up these distributed cloud functions...")
• Mandatory security training using customer slides ("Nothing says 'modern security' quite like skimming through another PowerPoint")
• Bans on virtualization and open source ("Let's pretend we can do better than everyone")
• Manual log review requirements ("Who needs AI-powered threat detection when you have humans manually reviewing logs?")

Add to that the truly bespoke requirements that don't scale for any vendor:

• Individualized disaster recovery testing
• Specific naming conventions for firewall rules
• Approval for every deployment and patch update

It's not just outdated, it's dysfunctional. And it stems from fundamentally misaligned needs:

• Enterprises need standardization across vendors
• SaaS providers need standardization across customers

Just like security professionals burn out trying to protect everything perfectly, cloud providers burn out accommodating every enterprise's unique requirements. And nobody wins.

The Broken Incentives That Keep This Madness Going

The incentives in TPRM are so broken they would make an economist weep:

• Vendors are incentivized to find any tweak imaginable to a question's sense to get to a "YES" any "NO" means endless "remediation" calls, no matter the requirement
• TPRM teams are incentivized to find problems to justify their existence
• Business units are incentivized to hide vendor relationships until the last minute to avoid TPRM delays
• Everyone is incentivized to pretend everything is "critical" because admitting otherwise means your program isn't taken seriously

The result? A system where nobody can be opened. A vendor can't admit they do something differently than your template expects. A TPRM analyst can't admit some controls don't matter for certain types of vendors. A business can't admit they need this vendor regardless of security posture.

So we get what we've designed for: a broken system optimized for documentation rather than security.

Breaking Free

Most companies get third-party risk management catastrophically wrong. Assessors send questionnaires, collect checkmarks, and turn every "no" into a finding demanding remediation. Vendors, on their side, misunderstand the whole thing by saying: "Our hosting provider is secure, we're good". The cycle repeats: pushing vendors to implement security controls that don't fit their business, forcing them to shift priorities, wasting time on what amounts to compliance theater. Instead of trying to fix every vendor weakness through endless remediation calls, look inward:

• If a vendor is terrible at security, don't waste months chasing them for improvements they'll never prioritize. Go to the business and tell them the truth: "This isn't a company we should build critical systems around. Don't tie your workflows to them. Don't invest too much energy here."
• When a vendor is solid, shift the conversation: "Why aren't we using them more? If they're more secure than another tool we rely on, why not consolidate? Why not replace the weaker option and reduce our overall risk?"
• And when you encounter a truly top-tier vendor, pay attention. Sometimes, the best security move isn't nitpicking... it's learning from them! What are they doing that you aren't? What can you bring into your own systems?

Third-party risk isn't about making every vendor perfect. It's about knowing where to push, where to contain, and where to learn. And maybe, it's about having the HUMILITY to admit we don't have all the answers, that our requirements aren't the one-size-fits-all solution to every security problem.

A Better Way Forward

Security isn't one-size-fits-all. There's no single "RIGHT" way to do security. But you already know that.

The solution to our TPRM nightmare requires acknowledging some uncomfortable truths:

1. Modern security is about architecture, not checklists
2. Scale requires standardization on both sides
3. Perfect security is impossible, resilience isn't
4. Trust comes from transparency, not control

To enterprises: Stop trying to force cloud-native vendors into on-premises security models. To vendors: Stop "yessing" on questionnaires just to make the sale. To TPRM professionals: Stop pretending your Excel spreadsheet constitutes actual security.

Instead:

• Focus on the risks that actually matter for your business relationship
• Adapt your requirements to modern architectures
• Embrace the reality that different vendors solve security differently
• Prioritize transparency over checkbox compliance

The real skill in TPRM isn't collecting YESes and closing gaps on the NOs. It's understanding what truly needs protection and having the HUMILITY to admit there's more than one way to get there.

TPRM should be about managing actual risk, not manufacturing paperwork. It should help businesses make informed decisions about their vendor relationships, not obstruct those relationships with security theater.

Which kind of TPRM program are you running?

Let that sink in for a minute.

While you're busy color-coding spreadsheets and perfecting your NIST mapping, AI is already writing better security policies than most GRC teams. It's automating framework mappings that took you weeks in seconds. And soon, it will be generating smarter risk assessments than your entire department.

If your GRC function is just a documentation factory or checkbox exercise, you're already obsolete. You just don't know it yet.

Think about these GRC professionals who build elaborate control frameworks and meticulous documentation while completely failing to move the security needle or gain allies. They're the first to complain that "nobody takes security seriously" while simultaneously making security the most painful, bureaucratic experience possible. They're a dying breed.

The compliance industrial complex is crumbling, and the only GRC professionals who will survive are those who recognize that security is about people, relationships, and delivering actual value. Not processes and paperwork.

The Death of Security Theatre

Let's be brutally honest: most of what passes for security and compliance today is just theater. Defined as: an elaborate performance designed to look good rather than actually protect anything.

As GRC professionals, we've become drunk on our own power. We make sure the company plays by the rules... our rules. We block projects. Stall deployments. Reject vendors. And we've convinced ourselves this is "doing security."

But here's the problem: when compliance teams go on auto-pilot, they stop enabling and start dictating. "To scale," "to standardize"... but let's call it what it really is: "to make our lives easier and justify our existence."

HR drowns in FBI-level background checks that make hiring impossible.

The Platform team suffocates under backup policies written by people who've never restored a system.

Engineers waste sprints implementing controls that protect against threats that don't exist.

Yes, we have the power to force this. That doesn't make it right. It makes us part of the problem. The most insidious part is that it's almost impossible to prove that a control has ZERO value. There's no ROI, but we're so afraid of "degrading our overall security posture" that we keep the charade going...

When we impose rules, people comply. But they don't own the outcome. As soon as you stop enforcing the rules, they will stop following them because you've provided them only with an extrinsic reason to act.

That's the difference between compliance and commitment, between following and owning.

The Signs Your GRC Program Is Failing

Look around your organization. If you see these symptoms, your program isn't just ineffective, it's actively harmful:

• Committees of people who don't do the work hold all the power, dragging decisions through endless cycles
• Every minor risk gets escalated to leadership where it dies a slow death in perpetual limbo
• You produce beautiful documentation that no one reads, references, or uses
• Engineers receive controls to implement like homework assignments with zero context

This isn't security. It's bureaucracy wearing a security badge.

GRC should solve problems, not manufacture them. But too often, we've become so infatuated with our processes that we've forgotten their purpose.

Escape Your Compliance Prison Before It's Too Late

You were hired because the company needed someone to "deal with that compliance problem." But is that really all you're capable of? Is that why you got into security?

I doubt it. And in the age of AI, being just "the compliance person" is a career death sentence.

Here are 3 radical moves to transform yourself from cost center to strategic asset:

Infiltrate the sales teams

Stop hiding in your compliance corner. Get aggressive about understanding your company's sales process. Learn their partnerships and B2B sales motions like your career depends on it. Because it kind of does. Build them that security FAQ they desperately need. Even better? Build a GPT to answer those questions automatically. Watch how quickly you transform from bureaucratic blocker to revenue enabler.

Forge an alliance with legal

Here's one of my biggest career revelations: GRC and legal speak the same language of risk and ambiguity. This is your ticket to business relevance. This partnership will transform you from "compliance person" to "strategic advisor" practically overnight.

Make finance and procurement your weapon

In our cloud-first world, every solution is quoted by user/month, and most companies are hemorrhaging money on unused licenses. Connect those dots between your purchasing teams and the IT folks managing IAM. Find those cost savings. Watch how quickly your Third-Party risk program becomes everyone's priority when you're saving them millions instead of just asking for documentation.

Your Secret Weapon: Connecting the Dots

While the rest of the organization is siloed, GRC professionals have a superpower that nobody else has: institutional knowledge that spans the entire enterprise.

We see every layer of an organization. We collaborate with everybody because security needs to be embedded everywhere. We interact with procurement to strengthen supplier relationships. We're twins with privacy. We influence HR processes. We meet with IT daily. We audit engineering systems.

If you work in B2B companies, you also touch sales and marketing. For the curious mind, this is the opportunity to absorb domains of knowledge, new approaches, and emerging projects all while being positioned to create connections no one else can see.

This knowledge is a cheat code for organizational influence.

Simplify, Don't Complicate

Want to know why nobody cares about your fancy data classifications? Because they shouldn't have to.

I learned this the hard way after rolling out an intricate matrix of color-coded data classification levels and subcategories of confidential PII to our procurement team so they could do some screening for us. I thought it was brilliant.

Procurement's reaction? They looked at me like I was describing my weekend D&D campaign.

Our fancy data classification matrix was nerd's gibberish. We were so deep in our expert bubble that we'd forgotten the cardinal rule: our job is to make complex ideas simple, not simple ideas complex.

Real GRC work isn't about creating spreadsheets to make academics proud. It's about translating risk into language that drives action. We don't need to prove how smart we are. We need to prove how valuable we can be.

Instead of dragging everyone through our complexity, we need to start with their reality. Our job is to abstract complexity, not create more of it.

Frameworks Are Not Security

Here's another inconvenient truth: memorizing every control in PCI, ISO, NIST, and SOC2 doesn't make you good at security. It makes you good at taking tests.

Think about music. You can learn to read sheet music perfectly, know every note, every chord progression. But if you never pick up an instrument, never play, never improvise, are you really a musician? Security is the same. Frameworks are the sheet music, but the real job is playing the music.

The real game in GRC is understanding the entire enterprise ecosystem: cloud, IAM, networking, DevOps, data, software architecture... and then cross-referencing these technical layers with business processes, market plans, and partnerships.

Sure, you can be "the PCI person." You can make a living off it. But if you lock in too early, you're pigeonholing yourself. You risk becoming a one-trick pony. Or worse, you get so tied to the framework that you stop thinking critically and just parrot whatever's in the document.

Frameworks are tools. They're not the job. The job is making security happen. And to do that, you need to go beyond the checklist and learn how it all fits together.

Lead with Solutions, Not Process

Want to actually fix security instead of just talking about it? Dare to walk the hard path. Lead with objectives, not checkboxes.

Instead of slamming down a compliance mandate, ask the real questions:

• What resilience scenario are we actually trying to address?
• What's the real security risk we're trying to solve with this hiring practice?
• How would this control actually prevent the attacks we're seeing?

Then work backwards from the problem, NOT from a so-called "hard" requirement.

Here's a secret the certification bodies don't want you to know: Almost all frameworks have intentionally vague requirements because the people writing them know compliance is never one-size-fits-all. They're giving you room to adapt: use it!

GRC is at its best when it builds a culture where security is about attracting people to work together on objectives, not enforcing a fossilized list of controls dreamed up by textbook authors and long-gone consultants.

The Path Forward

If you want to survive the AI revolution in GRC, here's your new playbook:

• Only escalate risks when a fix requires multi-team resources. Sometimes all it takes is a few sprint points to make meaningful progress.
• Stop forcing processes full of security jargon. Adapt to the team's existing workflows and tools instead of making everyone conform to your processes.
• Treat frameworks as starting points, not gospels. Your job is to tailor them, absorb the complexity, and make them actionable. Otherwise, you're just an expensive parrot.
• Eliminate approval cycles and committees that don't add value. They don't just delay decisions—they actively disempower teams and kill innovation.

The compliance professionals who will thrive in the next decade aren't the ones with the most certifications or the strictest controls. They're the ones who build relationships, solve real problems, and connect dots that others can't even see.

The best GRC teams don't just follow documents—they lead with relevance and action.

Which one are you going to be?

Most security initiatives fail because of inapt communications. Sometimes it’s resistance to change that we fail to address. Other times it’s confusion because you just put a cereal box of acronyms in everybody's plates. Occasionally, it’s straight-up indifference. And each time, someone on the team says, “We explained it clearly. Why don’t they get it?”

But communication isn’t clarity. It’s relevance.

Whether you're talking to an engineer who wants you out of the way, or a business lead with a target to hit, they can tell if you're reciting a playbook. They can tell if you care about their work, or just want them to care about yours.

And yes, it feels like selling... because it is.

Security doesn’t work without trust. It doesn’t scale without buy-in. And it doesn’t stick if people are only complying out of fear. Our job isn’t just to enforce controls. It’s to embed security in the way the organization thinks, builds, and grows.

But communication is also relentless repetition.

I’ve sat through countless “communications plans” that boil down to a policy update and an all-hands email. That’s not strategy, that’s broadcast. Message in a bottle. The average office worker gets 121 emails per day. A good newsletter "open rate" is 25%. Getting people to care about security requires influence, not information. It means stepping out of our expertise and stepping into theirs. And even if you make the message as tailored and relevant as you can: expect to repeat yourself a hundred times.

Culture Isn’t Built with Slogans

I’ve never liked the phrase “security is everyone’s responsibility.” It sounds inclusive, but it isn’t. What it actually does is spread accountability so thin that no one feels it anymore.

If you work in GRC, you know how this plays out. We tell ourselves we’re enabling a “culture of security,” but we end up recycling awareness training slides and wondering why nobody reads them.

Meanwhile, engineers roll their eyes. Salespeople avoid us. IT does their thing.

Then we get frustrated. “They don’t care about security until a breach occurs!”

But they do. They care enough to pay someone to think about it for them! That someone is you. It may not be the right way to think about security, but it is what it is. Management, when they hire you, buy peace of mind for that "security problem". "But they're just putting security in a little box and expecting us to fix everything, that makes no sense!" I know, but this is what they're buying. Expecting developers or product managers to prioritize security risks over deliverables is a fantasy. It’s our job to translate risk into relevance. That means understanding how their incentives work and meeting them there.

When We Pretend, We Lose

One of the worst mistakes I ever made was showing up to a data lake project like I already had the answers.

Data lakes are messy. It's basically your old Android phone's photo archive version of database storage. And in security, that makes us anxious. We want controls. Owners. Retention schedules. But walking in with a checklist and a smirk doesn’t win you credibility. Maybe you'll get a backlog ticket that never gets touched.

That project taught me something I try not to forget: Sometimes the most secure thing you can do is shut up and listen first. Today, when someone pitches a new AI-powered system or a new data-sharing tool, my instinct is still to scan for risk.

But I’ve learned to start with:

“Interesting idea. Let’s see how we can make this work safely.”

I mean, at our heart, we must remain excited by all of technology's possibilities. If we can't get excited, the spark is gone, and this is where we become bitter and old.

I’ve seen GRC teams lose influence simply because they showed up like lecturers. Like the engineers needed a reminder of the rules. That posture doesn’t just fail internally by the way. It poisons vendor relationships, too. Nobody wants to be told what to do by someone who doesn't understand what they do. I've suffered this countless times working for a SaaS vendor.

Your Heatmaps Don’t Speak for Themselves

We like to think our data will do the talking. That if we come armed with the right risk matrix or classification schemes, people will just get it.

They won’t.

Most people don’t think in frameworks. They think in outcomes. If you walk into a planning meeting talking about ISO controls and pseudonymized PII, you’ll lose them in five minutes.

What they want to know is: "How much will this slow us down? And what's in it for me?" Sure, there are plenty of people who want to do things right and will champion your initiatives. But assume they aren't.

If you can answer those things first, then you’ve earned the space to talk about audit logs, access tiers, or backup policies.

Don’t get me wrong. I’m not saying throw away your frameworks. But they’re your "infrastructure". Not your product.

If They Fail, We Get Fired

If people don’t care about security, that’s not their failure, it’s ours. We can’t keep blaming the business for not listening. We need to ask how we’re speaking. Because when the breach comes, no one’s pointing fingers at the ones who missed the webinar.

They’re looking at us.

Shared responsibility doesn’t mean shared consequences. It never has. It's unfair, and stressful. Kaspersky noted that in 31% of breaches, employees get fired; 45% of them are senior security employees.

So if we want security to succeed, we need to stop expecting everyone else to get it, and start making it impossible not to. That means selling security, not yelling about mandatory checkboxes.

Because in the end, nobody remembers the policies you wrote. They remember whether you helped, whether you listened, and whether they could build with you in the room.

And that’s the kind of GRC that actually gets things done.

I understand where the frustration comes from. But the reality is more complicated than they realize.

Because the truth is this: we can’t scale training the way they think we can. Not because we don’t want to. Not because we’re gatekeeping. But because this work is deep, complex, and requires time, trust, and repetition to learn properly. On-the-job security and GRC training isn’t something you can just do in front of an auditorium of people taking notes. No matter how motivated the person is, we can't just "toss them to the wolves" like that: they need to be relevant to our stakeholders.

I’m a Trainer. And I’m at Capacity.

I’ve been training people in cybersecurity for years. Yet, I can count on my two hands the number of people that I took from "making coffee at Starbucks" to "autonomous security analyst". I care deeply about helping others grow into this field. I wouldn't be a part-time teacher if I didn't (most of the pay goes to taxes). And now, as a manager and coach, I have even more responsibility—not just for outcomes, but for developing others.

But here's the honest truth: I can only properly train 1 to 2 people at a time. That’s it.

Not because I lack the will. But because real coaching isn’t about quick tips or dropping a few links in a Slack channel. It’s about building judgment, not just knowledge. It’s about having regular feedback loops, guiding someone through complex ambiguity, and letting them fail safely so they can learn from it. You can’t rush that. And you definitely can’t scale it beyond a handful of people at once, especially when you're still delivering on business objectives.

I say this because people often assume that trainers like me are holding back. That we could be doing more. That if we really wanted to help, we’d open the floodgates.

But what they don’t see is how much time and effort goes into mentoring even one person well. I feel I’m doing my part. And I know many others who are too.

GRC Isn’t a Soft Landing Spot

One of the reasons expectations get skewed is the way GRC is presented to newcomers. It’s often sold as the “easy” on-ramp into cybersecurity: “Don’t like command-line? Not into pentesting? No problem, try GRC: no coding necessary!”

This does real damage.

Because GRC isn’t beginner work. It’s advisory. It's "business oriented". It requires a strong grasp of technical systems and the ability to interface with legal, engineering, procurement, and executives, often in the same meeting. It’s not enough to know a framework or memorize controls. You have to interpret risk in context, communicate clearly under pressure, and manage tradeoffs that don’t have a right answer.

I see a lot of people show up with enthusiasm but little understanding of the depth involved. They believe that because they’re willing to learn, someone should be ready to train them. But GRC doesn’t work that way. It takes time. It takes repetition. It takes coaching.

And again: coaching doesn’t scale.

We’re Not Hoarding Knowledge

I think there’s a quiet resentment building in some corners of cybersecurity toward people already in the field. As if we owe knowledge to anyone who asks for it. As if we should just “give back” more.

But here’s the thing: you can’t transfer mastery in a few coffee chats.

You don’t learn how to think like a GRC advisor from a thread or a training video. You learn it by drawing diagrams, failing reviews, getting grilled in engineering meetings, and by making judgment calls (and living with the results).

That’s why GRC isn’t a “just teach me” field. It’s a “teach me how to think” field. And that kind of mentorship is precious, slow, and intimate.

So no, we’re not hoarding knowledge to keep the supply of security specialists low in order to maintain high wages. The skill level is just much, much higher to reach than what it looks like on the outside.

The Millions of Open Jobs Are a Myth

Let’s address the other elephant in the room: the idea that there are “millions” of cybersecurity jobs and that all you need is a good attitude to land one.

There are jobs, yes, but the entry-level ones are few and the ones that include structured training are even rarer. Pete Strouse, a cybersecurity talent advisor, tells on LinkedIn regularly about these stories of communities and bootcamps 20,000 strong who are fighting for 500 open jobs. Here's an uncomfortable truth: are you in the top 2.5%?

Most security programs are underwater, just trying to keep up with audits, assessments, vendor reviews, architecture changes, and incident response. They don’t have the time to build apprenticeships from scratch. Not because they’re evil. Because they’re barely staffed to meet current demands.

This is especially true in GRC, where training someone requires deep understanding of the relationships between technology and business and building relationships where compliance adds plus value. That kind of growth can’t be offloaded or outsourced. Picture this: if I tell a trainee to make sure a new product complies with the frameworks they've studied, how can this person do their work without just handing the piece of paper to the lead engineer to fill out for them? I've seen seniors do this...

What I Tell People Who Still Want In

If you’re serious about building a career in GRC, you need to understand the terrain.

Here’s what I usually tell people who come to me for advice:

• Start with understanding modern systems: IAM, cloud, SaaS, vendor ecosystems. GRC sits on top of real tech. Get hands-on.
• Build mental models: Learn to diagram how systems work and where risks emerge. If you can’t draw it, you don’t know it.
• Learn to translate: GRC is about turning tech talk into risk narratives and turning policies into real controls and somehow wrapping this up in dollars.
• Stop expecting it to be easy: It’s not. This is a tough field. And that’s okay. Hard things are worth doing.

Now layer on top of that the "people skills": exceptional communication, high emotional intelligence and strong negotiation aptitudes. The bad news here is that both of these are extremely hard to train. Be honest with yourself: is that what you really want? Selling people on doing things that add no business value and that often degrade user experience? Security is not cool, remember. Your job is to be the buzzkill when HR and marketing want to bring AI bots to do phone calls and when engineering uses Cursor with a personal license.

The Path Is Long, But It’s Real

To the people venting online, I say this with compassion:

You’re not wrong that it’s hard to break in. You’re not wrong that the market is tough. But don’t confuse that with a moral failure on the part of the people already here.

The failure is on the media and certification bodies selling you a pipe dream, that there's a whole industry waiting for you with open arms, ready to shower you with money.

Many of us are doing our best. Building teams, coaching juniors, fair hiring practices. But we also know the limits of what real development takes.

Building a career in cybersecurity isn’t about shortcuts or quick wins. The industry doesn’t owe you a job or an easy path. What it takes is deep, sustained effort, and the willingness to learn from failure.

So before blaming the system, recognize that real growth doesn’t happen overnight. It’s about developing real skills, judgment, and resilience, and those things take time.

This may sound harsh to some. I’ve heard the whispers: “Oh, GRC is for people who aren’t technical. It’s for those who don’t want to mess with the complex stuff like coding or systems engineering.” 🙄

But here’s the reality: If that’s how you see GRC, you’re missing the point. I'd go as far as to say you’re actively hindering your own growth.

I’m not here to sugarcoat things. GRC requires depth and it requires technical fluency. Let's see how.

Yes, your relationships and human skills are fundamental. People skills is what make you successful in the long run. But the technical skills get you there faster and protect you from hitting a glass ceiling.

The Myth of “Non-Technical” GRC 🚫💡

For years, there’s been this persistent myth that GRC is a non-technical career. The idea that it’s the “easier” path, one that lets you bypass the heavy lifting required in deep technical areas like coding, system architecture, or data protection. There are way too many influencers selling their bootcamps carrying this narrative, and it has to stop.

Risk management in the cloud is a perfect case in point. A GRC professional who doesn’t understand the intricacies of cloud-native services like serverless computing, IAM configurations, or shared responsibility models won’t be able to accurately assess risks, let alone mitigate them. You can't just drop a risk on an engineers plate and ask them to do all of the heavy lifting. You must abstract the complexity, use their own language and mental models. That's what I have in mind when thinking about "people skills": being relevant to individuals. And you can't be relevant without a certain amount of knowledge yourself.

If you’re sitting in a meeting discussing risk mitigation and someone casually mentions an AWS service, do you know how to ask about the implications of IAM policy misconfigurations? Or how a specific container security vulnerability might impact your infrastructure?

You can’t just rely on frameworks. You need to understand the systems. Otherwise, you are bringing complexity, not clarity. The GRC discipline is complex, we cannot afford to just relay messages and hope people understand our language. What use do we have if we do this?

Frameworks Aren’t Enough: You Need to Understand the Tech ⚠️📚

Here’s a harsh reality I want you to sit with: Frameworks are only half the story. They provide a structure, but that’s about it. If you’re just parroting control after control from ISO 27001, NIST, or SOC 2 without knowing the technical components driving those controls, you’re not doing GRC justice.

As an interviewer, I'll never care about whether people can name you the ISO 8.34 Control or the NIST RMF steps. I'll care much more about problem-solving, making the secure thing matter over the compliant thing, and marrying the two.

For instance, consider vulnerability management in a DevOps environment. It’s one thing to say you need to track vulnerabilities. It’s another thing entirely to understand the CI/CD pipeline, how static analysis tools integrate, or the shift-left strategy where vulnerabilities are caught during development, before they ever reach production. Frameworks don’t protect against the vulnerability introduced by failing to scan container images for outdated dependencies. Only technical understanding can.

You Can’t Protect What You Don’t Understand 💔🔐

This principle is fundamental. You can’t protect what you don’t understand.

I’ll tell you from experience: this is a constant learning process. You’re always going to feel like you’re out of your depth at some point. Imagine: nobody knew about most generative AI models before ChatGPT went mainstream. MCP servers were invented weeks ago. We are building the plane as we fly it. Can you catch up fast enough?

When I first started in GRC, I thought I could rely solely on framework knowledge. But soon, I was in meetings with engineers discussing API security and zero-trust models, and I realized that if I didn’t understand the tech, I was doing everyone a disservice.

Real GRC isn’t about just following rules or ticking off boxes. It’s about understanding how risk manifests in the context of your organization’s technology stack.

The Parrot vs. Architect Analogy 🦜🏗️

I have to drive this point home because it’s crucial: If you’re just parroting the language of frameworks without understanding the underlying tech, you’re missing the point.

A parrot repeats what it hears, it doesn’t understand the why. But an architect builds with intention and expertise, making strategic decisions based on a deep understanding of the environment. Real GRC professionals are architects. They aren’t simply filling out checkboxes, they’re actively constructing, advising, and ensuring that the security controls are effective in real-world systems.

I’ve been there. I’ve walked into a room where the engineers were discussing concepts I didn’t fully understand. Years in and I still don't fully grasp Kubernetes. (Yes, engineers often make thing much more complicated than they should, but that's another rant). In the end, I chose to lean into those uncomfortable moments. I asked questions, even if I felt I looked stupid. Don't make this a calculated thing, just be curious, be interested. The rest will follow.

Conclusion: Real GRC Means Understanding the Tech Stack 👨‍💻🔍

GRC isn’t just a role for process geeks or people who can recite standards by heart. It’s a technical discipline that requires active engagement with technology.

The good news is this: you don’t need to become a full-fledged engineer, but you do need to become fluent in the language of the systems that keep your organization running.

So, let’s stop pretending. GRC is technical, and it requires us to engage with the deep, messy, complex world of modern technology. If we want to be effective, we need to stop playing it safe and dive deep into the very systems we’re trying to secure. Only then can we truly protect what matters.

Final Thought 💭

If this resonates with you, I want you to know: you are not alone. Every GRC professional has felt that discomfort when faced with technical challenges. But embrace it. That’s where you learn, where you grow, and where you start making a true impact.

GRC is hard work. It requires vulnerability. But the depth of expertise you gain in the process will make all the difference when the stakes are high.

We’re in this together. 🌍💪

I equated being right with being effective. I believed that if I could clearly outline the risk, supported by the right policy, compliance would naturally follow. I thought my role was to win arguments. But the truth is, winning doesn’t build trust. And trust is where real, sustainable change is born.

This is why success in security is a question of human skills. Not the vague “soft skills” mentioned at conferences, but the deeply personal work: managing your emotions, your ego, your expectations; to negotiate effectively and to lead the way with practical solutions, not buzzwords, not spreadsheets and heat maps.

You Will Not Always Be Heard

I once believed that passion was synonymous with raising my voice, standing my ground, and making the risk impossible to ignore.

Here's what's actually impossible to ignore: speed, urgency, and hype. If you’re emotionally attached to your recommendations being executed exactly as you’ve outlined, you’re setting yourself up for burnout.

I’ve witnessed the destructive power of anger within a team. One angry GRC professional can drain a room of any willingness to collaborate. People avoid you. They stop sharing ideas early in the process. They stop reaching out for help.

A long time ago, I saw a colleague throw fits of rage over their considerations being brushed off by engineers. But here's the kicker: a few years later, all of the compliance considerations were handled. Sometimes, all you need is patience. The irony? When you let go of anger, people start listening.

You need to learn to play the long game. Sometimes that means staying silent, even when you’re right. Waiting for the right moment to reintroduce a risk. Returning not with “I told you so,” but with well-considered solutions.

It’s humbling, even frustrating at times. You might not look like the hero in the moment, but it’s how you build credibility that lasts.

I’ve sent snarky emails. I’ve escalated. I’ve dropped the “compliance requires this” hammer more times than I care to admit. It never worked long term.

Here’s the thing no one tells you about GRC: If your ego is wrapped up in being right, this job will break you.

We’re not here to win. We’re here to build.

The True Battle Lies Within

The most difficult lesson I’ve learned in GRC is that emotional detachment isn’t a sign of coldness, it’s a necessary survival mechanism. It’s the ability to show up, day after day, even when you feel overlooked or dismissed. Not to preach or reprimand, but to genuinely help.

In security, there’s no endpoint. No final victory. So stop treating every discussion like it’s a battle to win. Let the waves of disagreement wash over you. Be the calm in a storm of shifting priorities and competing demands.

Relationships Outlast Processes

Some of my most significant wins in GRC didn’t come from meticulously crafted risk registers or perfectly executed policy updates. They came from informal hallway conversations, a quick DM, or those spontaneous “Hey, security person” exchanges where trust is forged in the smallest of moments.

These moments won’t show up on your OKRs, but they are often the reason you’re invited into the room before a contract is signed, not after.

You don’t earn these moments by being efficient. You earn them by being human.

This Is the Work

Being relevant in GRC goes far beyond frameworks or tools. It’s about emotional intelligence. It’s about knowing when to push and when to pause. When to explain and when to simply be present.

Security is about trust. And trust isn’t built through policies or risk matrices. It’s built through people.

If you’re in GRC and this resonates with you, know that you’re not alone. This is the true work, the invisible, human-centered part that separates checkbox fillers from trusted advisors.

Let’s work together to build security cultures that people genuinely want to be part of.

Let’s do the human work.

This post is adapted from a collection of my most personal reflections on emotional intelligence in GRC. If this resonates with you, I encourage you to share your own journey or challenges in the comments.

Because someone in GRC needs to hear it from you.

It was my first time attending, and I went with a networking mindset. There were about 10 booths, many of which were government or government-backed startups. In other words: institutions that are not profit-motivated. None of the common security companies attended. The message struck me: there's no business in passion.

I can't think of a better illustration of how I've grown to see the cybersecurity profession: passion is fun but it's not the solution to protect our infrastructures from devious actors at scale.

Longtime readers know my story: I got into security thanks to the Mr Robot TV show: hacking for revolution at its finest! Nowadays, I write compliance reports and risk assessments for executives. In the future, I see this transition as the norm.

This is where I get provocative: I believe the future of security lies more in an accountant paradigm than in hacking. Slow and boring.

Pentest is overrated

A pentest job posting will garner more than double the applications for an incident responder role. And half of the candidates for the incident response role want to pivot into pentesting.

My TikTok videos about tractor hacking and deepfake sextortion were amongst my biggest hits. Hacking is cool! These feats rely on rare skill sets akin to magic for most people. Over the years, it's permeated pop culture and grown its aesthetics. Hoodies, anyone?

However, hacking suffers from a major flaw: it finds issues way too late in a product's lifecycle.

To me, pentesting should be a branch of compliance.

Let me explain: software building should follow guidelines, which create auditable artifacts. These artifacts then get correlated. Compliance systems trigger alerts upon guidelines being overstepped, leading to scrutiny. Pentests can become the ultimate weapon to verify application builders who trick compliance checks.

All companies, even small ones, must master their balance sheets and pay taxes. Accounting is a necessary hurdle. Wise accountants become business advisors. No decision gets taken without making sure that rules are followed. Pop culture also features these tasks as white-collar boring jobs.

I understand how accounting being tied to money gives it more gravitas than cybersecurity ever will. However, when I'm looking at how accounting firms are gobbling up all cybersecurity firms, I'm rooting for them.

Cybersecurity should not rely solely on the skills of a happy few. It should base itself on rules and, yes, red tape. I said it.

What does boring security mean in practice?

The cybersecurity of the future will look more like underwriting and accounting. Based on actuarial tables, cyber insurance systems will connect to companies' infrastructures to assess risks, based on the automated compliance data collection I've described above.

The systems will evaluate a given product's risks and based on a company's tolerance level, decide on whether additional scrutiny or resources must be allocated.

I also envision a security rating output, not dissimilar to the Common Criteria, but dynamic.

Humans will determine business outcomes, report findings, and fine-tune the systems.

How will we hook people to cybersecurity, then?

Keeping up with the accounting analogy, I believe young people should seek this area because it's good, steady, office jobs. It's awful boring, but it works.

Computer scientists and software engineers would remain crucial to build the artifacts-gathering systems, but all analysis could be carried out by people who are not experts in the underlying computing systems.

Perhaps this is it: we wouldn't need to hook them because the entry does not require extreme skills.

Most of the security specialists, myself included, spend their weekends and evenings thinking about security matters. This is such a staple of the job that I warn my students that this discipline will trample them if they expect a simple 9-to-5 and think about anything else the rest of the time. That doesn't scale. We need to lower the barrier.

What about advances in technology?

The rapid-evolving threats and technologies do weaken my comparison with accounting. Yes, tax codes change annually. But rarely do they force paradigm shifts similar to mobile devices, cloud computing, and large-learning models.

Advocating for a more standardized, rules-driven security means the rules must adapt. The aggregated compliance systems, the automated dynamic security rating and the adaptative actuarial tables I'm dreaming of cannot be built out of thin air. It's impossible to assess the quantifiable risks of LLM incidents. Social engineering, as a branch of cyber fraud, does not rely on flawed systems: it's a human problem. Maybe it shouldn't be a worry of cybersecurity anymore?

Technology moves fast, and cyber threat actors will always adapt more quickly than complex enterprise systems.

Does this mean this vision of a boring security will collapse? Do such limitations make sacrificing passion for white-collarism worthwhile? Time will tell.

What do you think? Tell us in the comments, or reply to this email to debate with me!

Verizon's Data Breach Investigation Report (DBIR) is one of the few reliable public data sources about the current state of security breaches and their associated costs. I expect cyber insurers to build detailed actuarial tables in the long term. Still, that enterprise may prove impossible: cyber threats are much more unpredictable than natural disasters, theft or vandalism.

We must cling to reliable sources such as the DBIR as an intellectual self-defence mechanism. Vendors and influencers need your fear to sell their salad. Just yesterday, a security awareness training vendor alarmed me on LinkedIn about "90%+ of breaches being due to humans", without providing a source...

I read the 2024 DBIR and here are some reliable conclusions.

Vulnerabilities Are Back In Style

I made the hack of the MOVEIt "secure" file transfer solution ppfosec's top story of 2023. The DBIR's data backs it up. Criminals could break into MOVEIt's software with a simple code injection, which made their lives easy. As a result, software vulnerabilities became a popular entry point, as much as stolen credentials.

Two conclusions emerge:

• Criminals will always use the path of least effort;
• You can't tunnel vision only on authentication.

Imagine if, next year, a piece of malware can execute on PDFs without macros, or a Javascript malware can break out of Chrome, or a WhatsApp WAV attachment can read into an iPhone's file system. Malware would become the #1 trend!

As much as I hate to write this: securing your systems based on headlines is not a stupid strategy. Yes, its reactive nature puts you behind, and I'd much rather build a comprehensive strategy around known standard practices. But still, I can't help but feel a quick fix for a small-medium enterprise is to follow the advice from reputable news sources!

Speaking of trends...

Generative AI is Nowhere to be Seen

In March 2023, I wrote How criminals will use generative AI to scam us. Looking back, I'm proud of this article because I still see publications, podcasts, journalists, and vendors throttling out the same ideas. I was ahead of the curve, yay! Or was I?

In the DBIR, the only mention of generative AI is ChatGPT Teams account selling on the black market. None of the scenarios such as AI-powered password guessing, ultra-realistic deepfake frauds, and well-written phishing emails happened.

Generative AI use in cyber criminality may be a cool academic discussion, but for now, it's speculative. In fact, given what we see in the data, I will be using this question as a "B.S. detector"...

Where the methods did change is...

Criminals Are Seeking New Revenue Streams

It might not appear so, but we are slowly winning against traditional ransomware. Based on FBI data, only 4% of ransomware victims paid the ransom (down from 7%), for a median loss of $46,000 (up from $26,000). Roughly speaking: the number of victims halved, and the criminals compensated by raising the price twofold. This reminds me of cable TV in the 2010s: twice the ads, twice the price, half the content.

The bad news is that hackers are finding less technical ways to extract revenue: fraud and extortion. Business email compromise (the biggest issue in the 2023 report) is still trending around 25% of breaches. Extortion is part of 10% of breaches, from 0% in 2023.

What is the difference between ransomware and "pure extortion"? Criminals will still breach your systems, lock you out, and ask for ransom. But they will also threaten to dox you to your regulators, customers, investors, and the media.

Initial analysis suggests extortion will have a short shelf life. Companies have become educated about security breaches and they'd rather face the music than pay the ransoms.

In short: we are getting better. And it's not the end...

Authorities' Initiatives Are Working

The DBIR feeds of FBI datasets. It gathers collaboration from the Cybersecurity and Infrastructure Security Agency (CISA). The CISA's catalog of "known exploited vulnerabilities (KEV) is built off a nationwide set of honeypots that can alert organizations of urgent threats within days, sometimes hours, of exploitation. The FBI took down the Qakbot ransomware, the Lockbit and Hive groups. I may be "drinking the Kool-Aid", but I'm forced to conclude that US institutions are performing both in awareness and enforcement, to tangible benefits.

It's not sexy to say we're winning, for obvious reasons. Security is infinite, and the minute we lower our attention, everything needs to be redone. We can't afford to sit on our laurels. Imagine if the trends I've observed this year end up reversing downwards for 2025. My optimistic take would look foolish. And that's the beauty of the doomsayers... if we call them out on their exaggeration, they could always say "better safe than sorry; hope for the best, prepare for the worst!" So I dare to believe our efforts are making a positive impact globally.

Do you share my optimism? Let us know in the comments!

Know What You’re Up Against: Insights from the 2023 Data Breach Investigations Report

Verizon’s Data Breach Investigation Report (DBIR) is a must-read resource to gain insight into current cybersecurity breaches. The 2023 version is out, and I read the whole 90 pages of it so you don’t have to!

ppfosecPierre-Paul Ferland

I love these interactions. As a GRC leader, I'm constantly hunting for these natural security champions in our organization. But here's what drives me absolutely nuts: the executives who shrug off security concerns like they're suggestions for the office Christmas party theme.

If you're reading this, I bet you've felt that same frustration.

There's a security consulting firm in my city with the slogan "Changing the world of security, one user at a time." It's inspiring. It's also complete nonsense.

For years, I've been obsessed with getting individuals to adopt secure behaviors. I've tried everything: security-by-default configurations, behavioral nudges, gamification, slick video content, community building... you name it. Notice what's missing from that list? Traditional security awareness training.

Why? Because "we need more security training" is usually what people say when they have nothing useful to contribute. It materializes usually in those mandatory corporate videos we all pretend to watch while answering emails. It's compliance theater at its finest.

But recently, I stumbled across an approach that completely flipped my thinking: What if instead of trying to educate thousands of employees, we focused laser-sharp on transforming the handful of executives who actually run the show?

The Leadership Leverage Point

Here's the uncomfortable truth about organizational change: metrics don't matter if nobody uses them.

I spent the last year building beautiful risk dashboards, compliance tracking systems, and predictive analytics tools. The data was clean, the insights were actionable, and the initial results looked fantastic. Then leadership changed, and the new executives defaulted to what they knew. All that progress? Gone.

I recently listened to an episode of Freakonomics podcast which tells the story of how the University of Chicago tried to fix policing by improving data and processes across thousands of departments. It failed because they couldn't scale leadership understanding. When trained managers left, their replacements had no clue how to use the new systems.

Sound familiar?

The breakthrough came when organizations shifted focus: instead of training 400,000 officers to follow procedures, they invested in training 4,000 leaders to build better departments.

Security Leadership Isn't What You Think

The most successful security transformations I've seen don't happen because executives memorize the NIST framework or learn to spot phishing emails. They happen when leaders genuinely understand how security connects to business outcomes.

The magic happens in three areas:

Strategic Integration: Executives who see security as a competitive advantage, not a cost center. They naturally weave risk considerations into hiring, project planning, and vendor decisions.

Cultural Psychology: Leaders who understand that lasting behavior change comes from motivation, not mandates. They know how to make security feel like a shared mission rather than imposed restrictions.

Peer Networks: When security becomes part of executive identity, it spreads horizontally through leadership ranks faster than any training program ever could.

The Multiplier Effect is Real

When a VP genuinely cares about security, their entire organization feels it. Not because they send stern emails about password policies, but because security considerations naturally flow into every decision they influence.

Their hiring managers start asking about security experience. Their project managers build risk assessment into planning cycles. Their teams actually engage with security requirements instead of treating them as roadblocks.

Security stops being "the team that says no" and becomes part of how business gets done.

Here's My Challenge to You

We have limited time and energy. The question isn't whether we can educate every employee—it's whether we're focusing our efforts where they'll create the biggest impact.

I'm convinced that converting a dozen senior leaders into security advocates beats running awareness campaigns for a thousand employees. The intimacy of executive education allows for deeper conversations, more sophisticated thinking, and sustainable behavioral change.

Plus, let's be honest: most awareness training is forgettable corporate content. Executive sessions can be engaging, strategic discussions that leaders actually want to attend.

What's your experience? Have you successfully converted senior executives into genuine security advocates? Or are you still stuck in the "awareness training for everyone" mindset?

The future of organizational security might depend on our ability to think smaller and aim higher.

Balancing security and privacy is tricky. I work daily with the privacy compliance team, to the point we call each other cousins. So how can we get at odds? To detect malicious activity, we need full visibility into network activity. On the other hand, privacy is about giving people the right to consent for what purposes they will allow companies to track them online. Whose interest takes priority?

The frustrating answer is "it depends". Based on the problems I've met, I adopted contradictory stances. Ambiguity is terrible for efficient communication but remains necessary.

Let me share some anecdotes where I encountered this tension. Hopefully, you'll be better prepared if you run into them in your work.

Privacy is not about "hiding"

One of the smartest security analysts I've met was a privacy freak. Before they were cool, he'd use a Librem privacy phone and many privacy gadgets such as TailsOS and Telegram.

He wasn't involved in hacktivism or citizen research. So why go to these lengths? To an extent, it was a game for him: how to defeat all these trackers?

On the other side of the spectrum, you have people shrugging off when they learn about Meta's extensive data collection and misuse: "I got nothing to hide". I bet you've heard that one.

I believe both extremes look at the problem in a "binary" fashion.

I see privacy as a choice rather than a "right to hide". Individuals must be informed of tracking and they must consent. That's not an entitlement to anonymity, nor an open bar for the trackers. I'll explore two cases to show you what I mean.

Mobile device management

I am still debating the merits of MDM software capabilities. As a security specialist, I need to enforce configurations such as password protection and block certain malicious apps and files from executing, plus perform a remote wipe of the device is stolen. This is "Mobile Security 101".

On the flip side, users are entitled to a degree of personal use of their machines. I would be deeply uncomfortable if a manager asked security for MDM logs to justify a firing. I'm not even delving into the legality behind these questions!

Can MDM protection be achieved without unintended consequences? This is where data about actual attacks can ultimately inform the decision:

• are cyberattackers delivering mobile-based malware or social engineering?
• could the MDM stop them?
• what does the organization stand to lose if nothing is done?

In the end, I have yet to fully flesh out a cost-benefit assessment to make up my mind about the current MDM solutions. Despite being a fundamental defensive measure, the privacy tradeoffs forced me to put into question the expected value I wanted to derive from an MDM.

Audit logs

As a security specialist, I need systems to generate logs of events that allow forensics investigators to establish events behind a cyber attack. Their conclusions must hold up in Court and follow the chain of custody.

As far as I'm concerned, cybercriminals do not have the right to be forgotten.

Nevertheless, it can appear silly to collect everything about users' activity on your public website for security purposes while your engineering team is building privacy-enhancing technologies to effectively avoid IP address collection in website analytics! As an engineer pointed out: "How long until the ads team figures out they've got all the data unmasked in the security logs?"

My conclusion remains to keep the breadth of the audit logs and compensate for privacy invasiveness with access controls, data lifecycle and monitoring. But I found the exercise of wondering about logs fascinating: as a security individual, I took for granted that audit logs were necessary. I had never wondered about them being used for other purposes!

Privacy is a supplemental cost of security measures

When teaching, I must deliver content about the ethics of cybersecurity. The crux of my interventions revolves around the idea that security analysts gain privileged access to sensitive information.

What I learned from being interested in privacy is that this "sensitive" information is not merely generated by "business applications" (customer records, trade secrets intellectual property, etc.) but that our security tooling could be misused for privacy invasiveness.

Another takeaway is the necessity to inform users. Sure, one cannot consent to being part of an audit log, this would defeat the purpose. However, users can know which measures we are implementing to guarantee minimum access.

Perhaps I could measure the rise of overall security transparency by the number of times people ask me worryingly if their employer is reading their SMS.

What do you think about the tradeoffs between security tooling and privacy? Tell us in the comments!