Sam Sawalhi is the Founder & CEO of JSOC IT, Inc., a Washington, D.C.-based cybersecurity and IT consulting firm, system integrator and service provider. By connecting to an organization's security stack and verifying its controls, JSOC IT's platforms Post-Security and READY work to quantify the gap between the self-reported security posture and the reality.
Sawalhi has spent more than 25 years in the industry as a virtual CISO, managing director, consultant, and advisor at Cisco, Netflix, First Residential, Vital Networks, ARK Telecommunications and other organizations, including MSPs and MSSPs.
He is featured in this ongoing leadership series developed by Cybersecurity Collaborative and SC Media, examining how experienced security leaders think about their role and its evolving challenges.
To learn more about the Cybersecurity Collaborative — a membership community where cybersecurity leaders collaborate in a trusted, peer-driven environment — click
here.
Below, Sawalhi shares his perspective.
How long have you been doing cybersecurity, and what kind of challenges have you faced?
My entire career has lived inside security operations: building programs, verifying controls, closing gaps, watching environments drift, starting again.
The central challenge isn't a technology problem. It's a belief problem.
Organizations believe their
MFA is enforced because it's configured. They believe their
endpoint coverage is complete because the dashboard says 98%. They believe their backups are clean because no alert came. That belief becomes the board narrative. The investor disclosure. The insurance application. The story everyone in the room quietly agrees not to question — until there's no choice left.
And then the breach happens. And the gap was there the entire time: measurable, exploitable, just never actually verified.
What I've watched throughout my career is smart, well-resourced security teams defending against a version of their environment that doesn't exist. Not because they're incompetent, but because the entire industry gave them tools to measure the wrong thing and present the output as truth.
The security industry gave organizations excellent tools for believing they're safe. We built the one that tells them whether they are.
What moment in your career most clearly marked your ascent into leadership, and what was the road that led you there?
It was the moment I stopped trying to fix broken security programs inside someone else's framework and accepted that the framework itself was the problem.
For years, I was doing the actual work: connecting to tools, comparing what was configured against what was actually defending, executing remediation manually in environments where nobody had done it before, and producing results that were real in a process that had no architecture underneath it.
The shift came when I stopped seeing it as one client's problem and recognized it as the industry's operating model. Every tool, every framework, every
audit checklist had been optimized for the same thing: measuring self-reported posture and presenting the output as security. They had not been optimized for verification, for evidence, or for the question that actually matters: Are you defended right now?
Leadership for me wasn't a title. It was the decision to name the problem publicly — before the market was ready to hear it — and build something that proved the alternative was real. The ascent wasn't a promotion. It was the moment I stopped waiting for someone else to build that thing and treated its absence as instruction.
What has surprised you the most about being a leader as your scope and visibility has increased?
How much of it is translation work. When you're doing technical work yourself, the distance between what you know and what you need to say is small. You see a misconfigured identity policy. You fix it. You document it. The truth is right there. The action is obvious.
As scope increases, that changes entirely. The truth is still right in front of you, but now it has to land differently in every room. There may be a board that doesn't speak the same language, a CFO who needs it explained as liability exposure, a prospect who needs it presented as business risk, or a team that needs it described as mission and meaning.
Learning to translate the same verified finding across those rooms — without losing the finding — is the most demanding skill leadership has required of me. Nobody warned me how much of the job it would eventually become.
The second surprise: Visibility creates accountability in both directions. When our main product started being cited, I understood that what we said publicly now carried weight it hadn't before. You can't lead a category and then go quiet when the category gets tested. The visibility commits you to the position.
What I didn't expect was how much I'd come to depend on that commitment. Say the uncomfortable thing out loud at scale, and you have nowhere to retreat from it. That turns out to be a gift.
How do you earn and maintain trust with your team?
By never asking anyone on this team to defend something I'm not willing to verify myself.
That's our operating principle applied internally. If the entire value proposition of our company is that self-reported scores are fiction, I can't run my team on optimism and assumption. Trust here is built exactly the way we build it with clients: Show your work, be precise about what you know and what you don't and do what you said you'd do.
I've learned that trust doesn't accumulate in the big moments. It accumulates in the small ones where nobody's watching. When I tell a colleague that I'll have something ready before a partner integration call and it's ready, that's the deposit. When I tell another colleague that her NIS2 architecture work is the backbone of our EU expansion and I mean it specifically, not generally, that's the deposit.
The balance builds quietly, and it's what you draw on when the pressure is high and the answer isn't clear yet.
What erodes trust fast is manufactured certainty. When a timeline slips or a platform issue compounds, I don't perform confidence to protect morale. I tell my team what I actually know, what I'm doing about it, and what I need from them.
People don't burn out from hard work. They burn out from hard work disconnected from something real. My job is to make sure that connection is always visible — not in tagline terms, but in the specific architecture of what we're building and why each person's piece is load-bearing.
When pressure is highest, what principle guides your decision-making more than anything else?
Accuracy over comfort. No exceptions, no situation-specific carve-outs.
When you're standing in front of a CISO whose board is demanding answers after an incident — or presenting verified posture data that returns 25 points below what their internal team reported — the pull to soften the finding is real. You could reduce the tension, give them something to feel good about, and let them leave the room with a better story than the data tells.
I've watched what happens when someone gives in to that pull. The gap doesn't close — it just becomes invisible. And invisible gaps are precisely what make breaches possible in the first place.
My team runs evidence-first. We don't assert, we verify. That discipline matters most when stakes are highest, because that's exactly when pressure to find a comfortable answer peaks. The moment you let that pressure move you, you've stopped being useful to the person who needed you most.
CISOs already have enough people in the room telling them what they want to hear, such as consultants, vendors, or internal teams with career exposure to protect. What they need, especially when the pressure is highest, is someone willing to say exactly what the data shows and then stand in the room while the room absorbs it.
That's the job. Softening the finding isn't protecting anyone. It's just redistributing the consequences.
What do high-potential leaders consistently misunderstand about what it takes to move to the next level?
They treat visibility as the reward for great work. It's actually the prerequisite.
I've watched technically brilliant people solve significant problems in complete obscurity — producing real results, waiting to be discovered. And I've watched people who were slightly less technically precise, but could name what they were seeing, frame it in terms of consequence, and say it in rooms that weren't ready to hear it — and move into leadership and define categories.
The skill that gets you to the next level isn't doing the work better. It's being willing to name the problem before anyone else has named it. That requires a specific kind of courage that technical excellence alone doesn't produce: the willingness to be wrong publicly, to stake a position on an inconvenient truth, and to hold that position when the room pushes back.
Most high-potential leaders are waiting for the right moment to speak. What they don't realize is that naming the moment is the act of leadership itself. The room never announces that it's ready. The leaders who advance are the ones who spoke anyway — not from certainty, but from the conviction that being right about the problem mattered more than being comfortable in the conversation.
And the position has to be specific. Vague conviction doesn't move rooms. "Security needs to improve" is not a stake. "Self-reported posture scores average 24 points above API-verified results" — that's a stake. That's what starts the conversation nobody else was willing to start.
What soft skills did you need as you moved up within the organization and managed teams?
The one I needed most, and had the least, was the ability to stay in a conversation long enough to actually change someone's mind.
Technical people — and I was one before I was a leader — tend to present the correct answer and then get frustrated when the room doesn't reorganize around it. The data is right there. The logic is sound. What's the problem?
The problem is that information has never moved anyone on its own. What moves people is feeling heard first, then challenged. I had to learn to listen past my own conclusion. That's harder than it sounds when you're confident you already have the right one.
Second: Giving people the why before the what. I naturally operate at the level of what needs to happen.
When I was only accountable for my own output, that worked fine. When I became accountable for a team's output, I learned fast that context isn't overhead — it's the infrastructure that lets people make good decisions without me in the room.
The quality of my team's independent judgment is a direct reflection of how clearly I've communicated the mission behind the task.
Third, and the one that surprised me most: Learning when not to fix things. My instinct when someone hits a wall is to solve it. I can usually see the path. But solving it every time quietly communicates that I don't trust them to find it themselves.
The most important shift I've made — from problem-solver to problem-framer — is also the one I'm still making.
How do you work to create a positive corporate culture, and how do you handle morale issues when they come along?
Culture isn't what you say in an all-hands. It's which behaviors survive under pressure.
The behavior I protect most aggressively at JSOC IT is accuracy. On a team whose entire market position is built on the gap between what organizations claim and what their tools confirm, intellectual honesty isn't a soft value — it's structural.
When someone says "I don't know," that's not a weakness. That's the culture working. When someone flags a problem before I've noticed it, that's not bad news. That's exactly what I hired them to do.
The moment people start managing information upward instead of surfacing it directly, the culture has already cracked. I try to make that impossible by making the alternative — radical transparency — consistently safe.
On morale: I've learned that almost every morale problem is an information problem in disguise. When people are disengaged, it's almost never about the work itself. It's about feeling like the direction shifted without explanation, or that their contribution isn't visible where it matters. The fix is more communication — more specific, more direct, more willing to say here is where we are, here is what's hard, and here is why it's still worth it.
What I don't do is perform optimism. People can handle hard stretches. What erodes everything quietly, faster than any setback, is feeling like leadership sees something different than what the team sees, and nobody's saying it.
The culture I'm building: Truth travels fast in every direction. Everything else follows.
What was the hardest decision you had to make as a leader?
Deciding to build the category instead of join one.
Early in JSOC IT, the easier path was available and obvious. We could have taken what we'd learned about verification, packaged it inside an existing category —
GRC, MSSP, compliance consulting — and gone on to sell it to buyers who already had the budget for it. Shorter sales cycle. Familiar positioning. Every smart person I talked to pointed that direction.
I didn't take it. And for a long time, that felt less like conviction and more like stubbornness I couldn't fully justify.
Building a new category means spending a significant portion of your early existence explaining why the old one is broken before you get to explain what you built. You lose deals to vendors that are easier to understand. You carry the weight of the positioning before the market has caught up.
What made it genuinely hard wasn't the external pressure. It was the internal accountability. The people on my team had made a bet on this vision too. Every week I chose the harder path, I was making that choice on their behalf as much as my own. You can tolerate your own uncertainty. You tolerate it differently when you've asked someone else to share it.
What kept me on the path was the data. Every time our platform connected to a new environment and returned a verified score 25, 30 points below what the client reported, the gap made the decision again. You can't build something that proves the problem is real and then package it inside the system that created the problem.
The hardest decision was the one I had to keep making — not just once, but every time the easier path reappeared.
What is the best leadership advice you have ever received and by whom?
"The room will always tell you what it wants to hear. Your job is to tell it what it needs to know."
A security executive I worked with early in my career said that. We'd just sat through a client presentation where a vendor had delivered a beautifully formatted posture report with a score everyone in the room privately knew wasn't real. Nobody said anything. The client nodded. The vendor moved on. After the meeting the security executive pulled me aside and said it quietly — almost like he was reminding himself as much as telling me.
I heard it at the time as permission to be direct — which I already was, sometimes to a fault. It took me years to understand what I'd missed.
Telling people what they need to know isn't the same as telling them what you know. It requires you to first understand what they're trying to protect, what they're afraid to say out loud, what decision they're about to make that the real information would change. You earn the right to deliver an uncomfortable truth by demonstrating that you understand what's at stake for the person receiving it.
That advice is the reason JSOC IT looks the way it does. Every design decision in our platform is an attempt to make it structurally impossible to tell the room what it wants to hear. We built the mechanism for delivering what organizations need to know directly into the product.
The best leadership advice I ever received turned out to be the best product design principle I ever had.
What leader do you most admire?
I admire three — and not for the obvious reasons.
Andy Grove. His doctrine of strategic inflection points is the framework I return to more than any other.
The argument is simple and brutal: There are moments when the fundamental assumptions of an industry shift, and the leaders who survive see the shift before it's comfortable to acknowledge.
What I admire most isn't the famous pivot from memory chips to microprocessors — it's that he documented the fear and disorientation honestly. "Only the Paranoid Survive" isn't a confidence manual. It's an admission that the right decision and the terrifying decision are often identical.
Katharine Graham. She inherited a company she wasn't supposed to lead and made two of the most consequential editorial decisions in American journalism — the Pentagon Papers and Watergate — under direct legal and political threat.
The specific kind of courage she demonstrated was not the loud kind, not the kind from certainty, but the kind that moves forward in the presence of doubt because the alternative is complicity.
Jensen Huang. He built infrastructure for a future that didn't exist yet and held the position for decades before the market arrived to validate it. The refusal to let present-day feedback define long-term architecture — investing in the truth of what's coming rather than the comfort of what's already here — is the posture I try to bring to my company every day.
The common thread: All three named something the room wasn't ready to hear, and built around the truth of it before the consensus caught up.
Is there a particular leadership book you would recommend? (Or is there a particular book/movie/event that you believe showcases extraordinary leadership?)
"The Alchemist" by Paulo Coelho. I'll own how that sounds coming from a CISO.
Most leadership books tell you how to execute. Coelho's is about something harder: how to stay on the right path when the easier one keeps appearing beside you. Santiago, the shepherd at the center of the story, spends the entire journey being offered comfortable stopping points — stability, safety, good enough. He keeps moving not because he's certain of the destination, but because something in him recognizes that settling would mean abandoning the truer version of what he's building.
That tension is the most honest description of what building JSOC IT has felt like. There were multiple moments where the comfortable version of this company was available: fit the product into a known category, shorten the sales cycle, stop making the uncomfortable argument about the honor system. The market kept offering the exit. The data kept pointing forward.
What Coelho understands — and what most frameworks miss — is that the hardest decisions aren't made once. They're made repeatedly, every time the easier path reappears. The book doesn't give you a model for that. It gives you something more useful: the recognition that the pattern is the journey, not a detour from it. The obstacle isn't blocking the path. The obstacle is the path.
I've read it more than once. I'll read it again.
What keeps you up at night?
The organizations that have passed every audit, satisfied every compliance requirement, and genuinely believe they are defended — and aren't.
The dangerous version of the gap isn't in organizations that know they have problems. Those teams are looking. The dangerous version is in the organizations that believe they don't have problems, because that belief becomes the board narrative, the investor disclosure, the insurance application. It becomes the story everyone in the room agrees not to question.
And then the adversary finds the 54 that everyone reported as 78.
In 2024, average adversary breakout time was 62 minutes. The industry average to close a verified gap was 89 days. There is no version of that math that ends well for the organization that mistakes its self-reported score for its actual posture.
What keeps me up isn't the threat landscape. Threats are constant. What keeps me up is the gap between what organizations believe about their defenses and what their tools would confirm — and the fact that for most of them, nobody has ever measured the distance. That gap has a name now. It has a measurement. It has a platform built to close it.
That's why we're still building at 2 AM.
What excites you about leading a team?
Not because I doubted them — but because they surprised themselves first.
I built JSOC IT intentionally small. Every person here was chosen because they're exceptional at something specific and genuinely motivated by the mission — not as a tagline, but as the actual work of replacing security theater with verified evidence.
Our integrations lead owns every API credential and partner relationship with a precision that makes the entire platform possible. Our identity architect is building NIS2 and zero-trust frameworks that are months ahead of what the market is asking for. Our endpoint engineer is executing remediations that most enterprise security teams can't do manually.
These aren't generalists being managed through a process. These are specialists being trusted with a domain.
What excites me is that trust compounds. The more clearly I communicate why their piece matters to the whole, the more ambitiously they build it. The more ambitiously they build it, the more the platform becomes something none of us could have designed alone. That emergent quality — where the output of the team exceeds what any individual, including me, could have produced — is the most extraordinary thing I've encountered in my career.
Leadership gets discussed mostly in terms of what the leader does. What actually excites me is what it makes possible for everyone else.
Leading is hard. How do you manage the stress of it?
I stopped trying to manage stress and started making it useful.
The stress of building JSOC IT isn't noise. It's directional. When I'm most anxious, I can almost always trace it to a specific gap — between where the platform is and where it needs to be, between what a client needs and what we've built, between what the category requires and where the market currently is. That gap has information in it. If I sedate it with distraction or performance, I lose the signal.
What I do instead: I write it down. Not journaling, but something closer to incident response. When pressure is highest, I create a precise picture of what I actually know, what I'm assuming, and what needs to be verified. The act of writing converts ambient weight into a specific list of things to act on. That alone usually cuts the anxiety in half before I've done anything else.
When a week is genuinely hard, I go back to the data. Not for reassurance — for grounding. I look at what our platform returned on a recent client engagement, and the actual delta between self-reported and verified. That number doesn't leave much room for self-pity. The problem is real. The stakes are real. My discomfort is considerably smaller than the consequence of not solving it.
The team is the third piece. When I'm carrying something heavy, I don't perform ease for them. I tell them what's hard and why it still matters. Shared weight is always lighter than carried weight.
What role do communities like CRA’s CyberRisk Collaborative play in your success?
CRC is where the real security conversation happens: not the marketed version, not the vendor floor pitch, but the unfiltered exchange between practitioners who are accountable for actual outcomes and cannot afford to nod along at platitudes.
For JSOC IT, these rooms serve a specific and irreplaceable function. When we present the verified-versus-self-reported gap data to a room of CISOs, they recognize it before we finish the sentence. They've lived it. They've stood in front of their boards with a posture narrative and privately wondered whether it was true. They've seen the questionnaire return 78 and felt the dissonance they couldn't name.
The validation this community provides isn't just business development — it's what turns a product into a movement.
Something happens in a room of practitioners when you say the average self-reported score is 78 and the API-verified score is 54. Nobody asks for a citation. They go quiet in the specific way people go quiet when someone has finally named what they've been carrying.
That's why we're here as Title Sponsor. Not to present a platform or run a demo. To say the quiet part out loud to the people who already know it's true — and to show them what it looks like when you replace the honor system with evidence.
This community is where Post-Security stops being a category argument and starts being a shared recognition.
