Every October, the inbox of Mark Sayewich, CISSP, fills up with the same thing yours probably does: phishing-simulation results and password-hygiene reminders. His organization runs a whole awareness season for our employees and it's a good habit to have. However, almost nobody runs the same thing for customers.
Disclaimer: The views and opinions expressed in this article belong solely to the author and do not necessarily reflect those of ISC2.
I see this situation every day. I’m a Director of Customer Security Evangelism. When my CISO first gave me that title, I couldn't explain it. Customers make real security decisions on their own and on most vendor teams, nobody owns making sure they can do it well.
|
Decision |
Who Usually Owns It, in Practice |
|
Identity and Access |
The customer, unassisted |
|
Configuration |
The customer, unassisted |
|
Data Handling |
The customer, unassisted |
|
Recovery |
The customer, unassisted and often assumed automatic |
On-premises software usually has the same lines of responsibility: a vendor builds it, hands it over and the customer's own team take it from there, usually asking questions along the way. The move to the cloud put everyone closer to that line and the consequences now arrive faster. A misconfigured setting can be internet-facing within seconds, before anyone holds a change-control meeting. A customer with an unanswered question doesn't wait long for an answer anymore, either. They ask a chatbot instead of asking us and whatever answer they get becomes the truth they act on, right or wrong. So, our own guidance needs to live somewhere a customer will actually find it.
The Blind Spot
Picture the moment a customer actually needs an answer. Mid-transaction, mid-configuration, whatever that looks like in your product. Most vendors aren't ready for that moment. We build great internal security programs, awareness training, phishing drills, the works. None of it reaches the person on the other side of the relationship who's about to make a real security decision alone. That leaves customers without guidance at the exact point they need it.
The awareness shortfall can be huge, one survey reported that 79% of IT decision-makers assumed their SaaS platform included backup and recovery by default.
Only the customer can usually turn on that setting. Vendors still have a role in making the responsibility clear and the action easy to take.
Move Beyond the Shared Responsibility Document
The standard vendor answer here is a shared responsibility document, sometimes 15 or 20 pages long, with a footnote somewhere in the middle saying, in effect, “yes, that one's on you.” I've sat in enough of these conversations to know how they go. A customer raises a concern, gets pointed to page 27 and reads a clause confirming that the thing they were worried about is indeed their responsibility. It's technically accurate, but I don't think a customer has ever read that document and felt more confident afterward.
A PDF can document responsibility, but it cannot build customer capability. Customers need to know what to do, why it matters and where to find help when they need it. Publishing the information is only the first step. The real test is whether customers can act on it.
That's the origin of the framework I use now, which I call “Customer Security Evangelism (CSE): a budget conversation.” When headcount and budget got leaner, I couldn't just point at work I'd been doing informally for years and call it done. I needed a way to grade the program the same way we grade any other security function, so I broke it into six domains.
|
Domain |
The Question It Answers |
|
Audience |
Who needs to act differently? |
|
Narrative |
What do they need to understand and do? |
|
Channel |
Where and when can we reach them? |
|
Trust |
Why should they believe the guidance? |
|
Measure |
Did understanding become behavior? |
|
Coordinated Evangelism |
Can providers reduce confusion together? |
Each domain leads to a practical decision. Audience starts with segmentation because a brand-new prospect and a 10-year customer need different things. Narrative adapts the same information for the CISO, the admin and the end user instead of sending one document to all three. Channel puts the guidance somewhere people already check and trust, rather than in a white paper buried in a portal. Trust depends on being as clear about what you don't know as what you do. An overconfident vendor and an untrustworthy one sound the same to a customer. Measurement shows whether the guidance led to action.
That last domain, Coordinated Evangelism, matters more than it sounds like it should. Customers rarely have just one vendor. When two providers describe the same shared-responsibility idea in slightly different language, the customer's the one left reconciling it. A customer security program is supposed to save them from exactly that kind of work.
CSEF is my own working practice, refined against real programs, rather than an established industry standard.
Three Things Any Vendor Can Do Now
Any vendor can start with three decisions.
|
Do This |
Not This |
Why |
|
Pick one customer behavior to change (e.g. “enable this setting”) |
“Improve customer security awareness” |
A vague goal produces no action; a named behavior produces a checklist |
|
Segment the ask by audience |
One message for everyone |
The same fact needs a different frame for a CISO, an admin, and an end user |
|
Measure whether the behavior changed |
Measure views, downloads, and attendance |
Reach is an input. Behavior change is the outcome |
Pick one behavior. “Improve customer security awareness” is too broad to guide an action or measure a result. Name the one thing you want a customer to do differently this month, such as enable a setting or rotate a credential. That gives you a concrete checklist instead of a slide nobody remembers by November.
Segment the ask. Here's the same fact, said three different ways:
if audience == "CISO":
message = "This backup gap is a board-level risk exposure."
else if audience == "IT admin":
message = "Here’s the setting. Turn it on this week."
else: # end user
message = "Save your work here, not just locally."
Each audience gets the same underlying fact in language that reflects their role. Send the CISO version to the admin, or vice versa and perfectly accurate content gets ignored simply because it wasn't written for the person reading it.
Measure what changed. It's easy to build a slide that says “800 downloads, thousands of views” and feel like the program's working:
- Views, downloads, attendance: that's reach. In isolation it doesn't tell you much
- Did the behavior actually change? That's the number worth caring about
For the backup example, track how many customers turned on the setting. That result shows whether the guidance changed behavior and reduced risk, giving you a much stronger case for continued investment than a download count.
Start Now
Customers will make these choices whether or not you guide them. They’ll configure the product, assign access and decide whether to turn on recovery. Without clear guidance, they may turn to an AI-generated answer or a confident-sounding forum post instead.
We already accept that employees need a deliberate, budgeted, measured security awareness effort every year. Customers make decisions with comparable stakes. Their customers or policyholders may depend on a choice made by someone who never got a straight answer to a simple question. Giving that person clear, timely guidance belongs in the security program.
Start with one customer action you can influence. Tailor the message to the person responsible for taking it, then track whether they do. A measured result gives you the evidence to build an ongoing program.
Mark Sayewich, CISSP, has over 40 years of experience in technology, including more than 20 years in the insurance industry. He has held technical, leadership and customer-facing evangelism roles, with responsibility for translating security risk into business language for decision-makers, from the developer’s IDE to the executive boardroom. His cybersecurity work spans customer security evangelism, awareness program design and threat modeling.
.png?h=420&iar=0&w=420)
.png?h=420&iar=0&w=420)
