The hardest part of building a security program is getting people to care.
When I moved from traditional IT and security roles into specialized programs, first in SaaS governance, now leading AI security work, I found out fast that technical skill wasn’t enough on its own. I could identify vulnerabilities and implement controls. What I couldn’t do alone was build enough trust across the organization for security to stop being only my problem.
Most of the job turned out to be translation: connecting security requirements to whatever the business was actually trying to do.
Saying no just made teams work around us
My first real lesson came on a SaaS governance team. We were assessing risk across a fast-growing portfolio of SaaS applications. On paper it looked simple: discover the apps, build a risk framework, evaluate them, approve or deny, or hand over a risk report and let stakeholders accept or reject the risk themselves.
In practice it was a communication problem.
Teams were already using dozens of tools, many of which we didn’t even know about. If we came in with a strict “security says no” approach, people would either go around us or demand we be cut out of the process entirely. Neither outcome made anyone safer.
So the team and I started hosting webinars and sitting in on department calls, mostly to explain how SaaS security differs from the traditional kind.
Salesforce secures the infrastructure, we secure the configuration
In traditional on-premises environments, security teams controlled almost everything: the hardware, the network, the OS, the applications. We could harden the systems, manage who got access, and watch the traffic, all on our own terms.
SaaS changed that completely.
I spent hours explaining the shared responsibility model. “Yes, Salesforce secures their infrastructure, but we decide who has access, what permissions they have, and how our data is configured. A SOC 2 report doesn’t replace our due diligence.”
The best results came when I asked questions instead of issuing rules: “What problem are you solving with this tool? What data will it touch? Who needs access?” When teams felt heard, they brought us in earlier.
Teams started coming to us before signing contracts. Reviews became part of how they chose a vendor.
AI moves faster and the risks are less defined
Those early lessons carried straight into AI security, where they mattered more. The technology moves faster and the risks are harder to pin down. I work with development teams through the whole lifecycle now, and sprint demos have turned into one of my best tools.
Developers ignore security when it feels abstract
Caring isn’t the problem. Developers tune security out when it feels disconnected from what they’re shipping, so I changed my approach.
During sprint planning and demos I try not to just say “sanitize inputs” or “check authentication.” I explain what breaks if we don’t.
“This feature lets users upload training data for the model. If we don’t validate file types or scan for malicious content, someone could poison the model or access data from other users. Let’s figure out how to handle that safely without slowing the experience.”
Security ends up part of the feature itself (shift left anyone?).
We review CVEs with the developers now
Patching used to feel like a fight. Security would send a list of CVEs, set a deadline, and wait for it to happen, developers would push back, and nobody got what they wanted.
Now when a new CVE affects our stack, I sit down with the developers to review it. We look at the details: How does it work? Does it apply to our setup? What’s the right timeline to fix it? Are there short-term mitigations?
Developers come out of those reviews understanding the actual risk, and they can tell that security respects what they know.
Recently we found a critical vulnerability in a Node package. Instead of forcing an immediate patch that would have delayed release, we verified that our implementation didn’t expose the vulnerable code path. We documented the decision, added monitoring, and scheduled the update for the next sprint. Nobody argued about it.
Culture is what people do when nobody is checking
A security program is a set of policies and procedures. What I actually care about is whether people make the secure choice when no one is watching, and you can’t write that into a policy.
You can’t enforce it either. It grows out of explaining things clearly and following through on what you said you would do.
I explain the reasoning behind every requirement
Not as a lecture, just the same way I would explain it to a colleague who asked.
Why MFA on this SaaS app? It handles customer data, and passwords are still one of the easiest ways in. Why we are careful about what goes into AI training data: anything sensitive that goes in can come back out later. Why we require API rate limits? Without them, someone can automate credential stuffing or scrape data at scale.
When people understand the reason, they apply that logic to new situations without needing constant oversight.
I make sure security wins get noticed
When a developer spots a potential injection risk during code review, I make sure their manager knows. When a product team asks about security implications during design, I call it out in meetings.
The long game
This approach takes patience. It’s slower than just enforcing controls, and the results hold up better.
Today I spend less time convincing teams to think about security and more time helping them build it. Our SaaS tools get vetted properly because teams know what good looks like now. The policies aren’t any stricter than they were. Our AI products are safer because developers think about risk while they’re building, which gets further than me catching everything after the fact.
The technical work still matters. Risk assessments, architecture reviews, vulnerability management, all of that. A program without the communication around it still struggles.
Security is something you build with an organization. I don’t think you can do it to one.