customer security evangelism framework
Every SaaS platform invests heavily in securing its own infrastructure. Almost none invest in building the security capability of the people using it. That gap is where incidents live, and it's where CSEF starts.
NIST CSF 2.0, the CIS Controls, and the CSA Cloud Controls Matrix answer important questions about outcomes, controls, and responsibility. None of them answer a different question: how should a SaaS provider systematically build security awareness, behavior, and capability in the customers who share its risk?
In a November 2023 Rewind survey of 419 IT decision-makers, 79% said they believed SaaS applications include backup and recovery capabilities by default. What providers actually include, and what customers must protect themselves, varies by product and contract. The result shouldn't be generalized to every SaaS customer or responsibility; it's evidence that important assumptions can remain hidden even among IT decision-makers.
Customer Security Evangelism is the structured practice of building security awareness, changing security behavior, and increasing security capability within a provider's customer base to reduce shared risk. Its primary output is a more capable and secure customer.
Each domain can be assessed against CSEF's own four-level practice-maturity model: Reactive, Defined, Measured, Adaptive. These are CSEF-specific levels, not NIST CSF Tiers.
Understand who the program needs to reach, what they currently believe and do, and what could move them to act.
Translate technical security expectations into accurate, actionable communication for a specific audience.
Deliver the right intervention through the right channel, messenger, and moment.
Earn the confidence required for customers to believe and act on security guidance.
Determine whether the program changes customer capability, and use the evidence to improve it.
Extension: help providers serving shared customers reduce contradictory guidance and improve collective learning.
Working draft v0.2. Mark Sayewich, July 2026. A working model to test, not an industry standard or a claim that one company has the final answer.
SaaS providers invest heavily in securing the services they operate. Customers still make security decisions about identity, access, configuration, data, integrations, recovery, and use. Control frameworks and shared-responsibility models help describe those obligations. They do not tell a provider how to build the customer's ability and motivation to meet them.
Many providers already perform pieces of this work through documentation, customer success, product security, trust, training, community, and executive engagement. The practice is rarely treated as one operating discipline with clear boundaries and outcome measures.
Customer Security Evangelism Framework (CSEF) is a proposed synthesis of that discipline. It is based on operating experience and ideas adapted from security frameworks, social and behavioral change, health literacy, diffusion research, and program evaluation. It is a working model to test, not an industry standard or a claim that one company has the final answer.
NIST Cybersecurity Framework (CSF) 2.0 provides a taxonomy of cybersecurity outcomes. The CIS Controls prioritize technical safeguards. The Cloud Security Alliance Cloud Controls Matrix (CCM) helps cloud providers and customers identify control applicability and ownership across cloud-service models.
These sources answer important questions about outcomes, controls, and responsibility. CSEF addresses a different question:
How should a SaaS provider systematically build security awareness, behavior, and capability in the customers who share its risk?
That question matters because documenting responsibility does not ensure that a customer understands or acts on it.
of 419 surveyed IT decision-makers believed SaaS applications included backup and recovery by default. What providers actually include, and what customers must protect themselves, varies by product and contract — the gap is evidence that important assumptions can remain hidden even among IT decision-makers.
Customer Security Evangelism is the structured practice of building security awareness, changing security behavior, and increasing security capability within a provider's customer base to reduce shared risk. Its primary output is a more capable and secure customer.
It is distinct from:
Customer Security Evangelism collaborates with all of these functions. It loses credibility when customers cannot distinguish its security guidance from a commercial message.
CSEF uses six principles:
CSEF has five core operating domains. A sixth extension applies when multiple providers coordinate for shared customers.
CSEF maturity levels. Each domain can be assessed using four CSEF-specific levels. This grades the provider's own program, and is a separate scale from customer security maturity (see Domain 1 below):
| Level | Name | Meaning |
|---|---|---|
| 1 | Reactive | Work is ad hoc, request-driven, and dependent on individual effort. |
| 2 | Defined | Purpose, ownership, audiences, and repeatable practices are documented. |
| 3 | Measured | The program uses evidence to assess reach, behavior, and capability outcomes. |
| 4 | Adaptive | Customer evidence continuously changes priorities, design, and delivery. |
These are CSEF maturity levels. They are not NIST CSF Tiers. NIST Tiers characterize the rigor of cybersecurity risk-governance and risk-management practices; CSEF uses its own levels to assess an evangelism program.
Each domain below is summarized — expand any for its full purpose, key practices, and sourcing.
Purpose: Understand who the program needs to reach, what they currently believe and do, and what could move them to act.
Security guidance lands differently with a CISO, cloud administrator, developer, risk leader, and executive sponsor. Effective work begins with evidence about the audience rather than assumptions about an "average customer."
Key practices:
Customer security maturity is deliberately its own informal, qualitative band, distinct from the CSEF program-maturity levels above, used only for this kind of segmentation:
The approach is informed by social and behavioral change practice. UNICEF's guidance recommends audience research, social listening or interviews, and attention to culture, language, literacy, trusted messengers, and current awareness before designing messages. The Health Belief Model is one useful lens for exploring perceived risk, expected benefit, barriers, cues to action, and self-efficacy; it is not a universal predictor or a CSEF measurement system.
Purpose: Translate technical security expectations into accurate, actionable communication for a specific audience.
Key practices:
CDC defines plain language as communication an audience can understand the first time and recommends knowing the audience and purpose, putting the most important message first, using active voice, and limiting sentences to one idea. CSEF applies those principles to security communication.
Purpose: Deliver the right intervention through the right channel, messenger, and moment.
Key practices:
Channel is part of the intervention. A correct message delivered where the intended audience will not see or trust it is not effective communication.
Purpose: Earn the confidence required for customers to believe and act on security guidance.
Key practices:
Diffusion research emphasizes that adoption moves through social systems and is influenced by communication channels and opinion leadership. CSEF applies that insight without assuming that every customer community behaves identically.
Purpose: Determine whether the program changes customer capability and use the evidence to improve it.
Key practices:
CDC's current Program Evaluation Framework recommends assessing context, describing the program, focusing the evaluation design, gathering credible evidence, supporting conclusions, and acting on findings. CSEF borrows that learning discipline rather than claiming a security communication can always be isolated as the cause of a risk outcome.
Purpose: Help providers serving shared customers reduce contradictory guidance and improve collective learning.
Key practices:
FS-ISAC demonstrates how a member-driven community can build sector-wide visibility and resilience through trusted information sharing. CSEF does not claim that coordinated customer evangelism is equivalent to financial-sector threat intelligence. It borrows the principle that shared systemic problems sometimes require trusted coordination.
| Source | What it contributes | What CSEF adds |
|---|---|---|
| NIST CSF 2.0 | High-level cybersecurity outcomes, Profiles, and Tiers for risk governance and management | A customer-facing program for building understanding and capability around relevant outcomes |
| CIS Controls v8.1 | Prioritized safeguards and Implementation Groups | Audience-specific translation and adoption support |
| CSA CCM v4.1 | Cloud controls plus provider/customer applicability and ownership | A practice for helping customers understand and act on their responsibilities |
| OWASP Security Culture | Guidance for security culture in application-security and software-development programs | A distinct focus on the external customer base of a SaaS provider |
| UNICEF and CDC communication guidance | Audience research, behavior-aware messaging, plain language, and program evaluation | Application of those disciplines to customer security |
CSEF is intended to complement these sources, not replace or imply endorsement by them.
An organization can begin without launching every domain at once:
CSEF v0.2 should be treated as a hypothesis expressed clearly enough to test.
Recommended next steps:
OWASP already maintains a Security Culture documentation project focused on application-security programs. Any CSEF proposal to OWASP should explain its customer-facing scope and begin with consultation rather than an assumption that a separate project will be accepted.
A save-and-forward version, for anyone who'd rather read this offline or hand it to a colleague. Use your browser's print function and save as PDF, it's set up to print cleanly.
Mark Sayewich is Director of Customer Security Evangelism at Guidewire Software. His work focuses on helping insurance customers and partners understand shared responsibility, apply practical security guidance, and strengthen security capability. He presented on Customer Security Evangelism at ISC2 Security Congress 2023 and is developing CSEF as a vendor-neutral working model for peer review.
This version reflects early conversations with Guidewire colleagues and security practitioners. Individual reviewers and contributors will be credited with permission in future versions.
No external standards body, conference, industry group, or employer has endorsed this working draft. Guidewire is identified as the author's employer, not as the owner of an industry standard. CSEF is Mark's individual working hypothesis, built from hands-on experience, offered here for peer review.
CSEF is a work in progress, not a finished standard. Found a gap, have a counterexample, or want to pilot a domain? Open an issue or a pull request at github.com/sayewich/cseframework.