Objectives Before Rhetoric

In our August newsletter, we introduced Barbara O'Keefe's message-design logic theory. Sign up for the Discernible newsletter here if you missed it and want the full breakdown. This post picks up where that issue left off.

O'Keefe's framework identifies three ways people conceptualize communication. 

1. Expressive logic treats a message as a direct channel for stating thoughts. 
2. Conventional logic treats communication as a rule-governed exchange, following etiquette, roles, and established scripts. 
3. Rhetorical logic treats a message as a tool for negotiating a shared reality, one that can serve multiple objectives at once. 

Decades of research on this framework find that rhetorical messages get judged as more competent, particularly in situations where the objectives are in tension with each other.

Security and privacy teams live inside all of these situations. For example, an incident update has to be accurate, timely, and reassuring, often to audiences who have conflicting interests in what "reassuring" even means, while a new security policy or tool rollout has to change behavior without making people feel surveilled or blamed. These are rhetorical problems by definition, but most practitioners never get to apply rhetorical logic because they haven't yet defined what the communication is supposed to accomplish.

I realize that even the term “rhetorical logic” might sound too academic for some people, so here’s the gist: the potential impact of your communications is directly tied to how well you understand what the message needs to do. If you haven't done that work, you default to expressive logic (i.e. say what's technically true and hope it lands) or conventional logic (i.e. follow a static template or playbook) because you don't have a handle on an objective to design around. This is one of the most common issues I see working with security teams. Many self-proclaimed “good communicators” are focused so much on tactical execution, they’re really surprised when someone’s reaction reflects just how far they missed the mark.  

I was working on incident response with a security team, whose historical post-mortem default was to report what happened, in the order it happened, because they didn’t have any other defined communication objectives beyond simply publishing a report. This approach made it very difficult for customers to consume the details with an accurate understanding of importance and priority. It also forced them to scroll through a lot of text to find what they needed. 

Once we decided the objective was actually to preserve the trust of enterprise customers while the investigation is ongoing, they wrote a completely different update, even though the underlying facts were the same. It was a completely different message design, not merely word-smithing. The team now knew what the communication needed to accomplish and that informed just not what they wrote, but how.

The same gap shows up in policy rollouts. Teams that haven’t defined the communication objective beyond "explain the new policy" often produce an explanation. That’s better than saying nothing, but it’s not really enough. However, if you can be specific in your defined communication objectives, such as "get engineering leads to enforce this without escalating to us every time," the finish line moves to produce something built to change behavior, not just transfer information. To be clear, both documents can be factually correct, yet only one of them is designed to do something.

The second piece of this that gets missed is that rhetoric was never about your word choice. It's about their interpretation.

Most security practitioners still approach message design from the sender's perspective. They’ll ask what the most accurate word is or what the most technically correct phrasing is to find something that sounds right to them. But rhetorical logic doesn't work from the sender's preferences. It works from how the recipient will receive and interpret what you send them, given their existing beliefs, their incentives, and what they're already primed to assume. The same sentence can land as reassuring or alarming, as a status update or an admission of failure, depending on who's reading it and what they walked in believing. Choosing words based on what feels precise to you, rather than what the recipient will do with them, is expressive logic and puts a limit on how impactul your message can be.

This is why objectives have to come first. You can’t design for a recipient's interpretation if you haven't decided what you need that interpretation to be. Objective setting is the thing that makes rhetorical logic possible.

The next time your team sits down to draft an incident update or a policy announcement, skip the template for five minutes. Write down what you need the reader to believe, feel, or do differently once they've read it. That sentence is the most important thing you’ll write.

Here’s a simplified example to illustrate how different objectives drive different execution for something like an incident update: 

Incident Facts:

• unauthorized access to an internal admin tool was detected and contained within 6 hours. 
• No customer data was accessed. 
• The root cause was a misconfigured access control that has since been fixed. 
• Enterprise customers have been asking your account team for updates.

Version 1:

• Objective: report what happened (no defined communication goal beyond "keep people informed")
• Message: We detected unauthorized access to an internal admin tool on July 29. Our security team identified the access within 6 hours and revoked the credentials involved. Our investigation found the access was caused by a misconfigured access control policy. We have since corrected the configuration. Our investigation determined that no customer data was accessed during this incident. Please let us know if you have any questions.

Version 2:

• Objective: preserve enterprise customer trust while the investigation is ongoing
• Message: On July 29, our monitoring flagged unauthorized access to an internal admin tool, which we contained in under 6 hours. Our investigation confirmed that no customer data was accessed and the root cause was a misconfigured access control. We've corrected it, and we're adding automated policy drift detection that flags any admin tool whose access controls deviate from our baseline IAM configuration within minutes. Happy to walk your security team through the full timeline if that's useful.