There’s a certain kind of security meeting that feels productive while achieving very little.
The right people are there. Slides are shared. Someone says “Let’s align”. Someone else says “We should socialize this”. A third person asks for a follow-up meeting with the broader group. 45 minutes later, everyone leaves with the same information they had before, plus three new action items and no actual decision.
This is one of the quieter reasons security work gets stuck.
Security teams often assume that decisions happen in meetings. In modern work, they usually shouldn’t.
Meetings are useful for a few things: conflict resolution, rapid clarification, trust-building and situations where live discussion genuinely changes the outcome. But most security decisions are not blocked by lack of conversation. They are blocked by lack of clarity before the conversation starts.
That distinction matters.
Because most of the time, security decisions belong somewhere quieter, sharper and more accountable.
The core problem: meetings reward reaction, not thinking
A security decision usually has four components:
-
The question being asked
-
The relevant context
-
The available options
-
The recommended tradeoff
That work is better done before people enter a room.
Meetings are poor containers for first-pass reasoning. They reward whoever speaks first, whoever sounds most confident or whoever holds the most organizational power. They also encourage a specific kind of security failure: replacing written clarity with verbal approximation.
That is how you get decisions like:
-
“Let’s be conservative for now”
-
“Can we just add an approval step?”
-
“I think Legal should weigh in”
-
“Maybe let’s revisit after the audit”
-
“We’re directionally aligned”
None of these are decisions. They are social placeholders.
And placeholders are expensive.
Why this gets worse in security specifically
Security carries a special kind of meeting gravity because it sits near risk, compliance, engineering, legal, procurement, privacy and leadership. Everyone has an opinion. Nobody wants to be the one who approves something risky in real time. So the meeting becomes a risk-distribution mechanism.
That sounds responsible. It usually isn’t.
When nobody wants to own the decision, the meeting becomes a place to dilute accountability. The issue gets “discussed” by a group, which makes everyone feel involved and nobody clearly responsible.
You’ve probably seen versions of this:
A product team wants to launch a feature that uses a new vendor API. Security raises concerns about data flow, access scope and retention. A meeting is scheduled with Product, Engineering, Privacy, Legal and Security. 40 minutes are spent re-explaining the feature. 10 minutes are spent debating edge cases. Someone asks whether the vendor has a SOC 2. Another person asks whether the use case is “really sensitive”. The meeting ends with “Security and Privacy to follow up with recommendation”.
That recommendation was the only thing that actually mattered. The meeting was just expensive preamble.
Most security decisions are writing problems first
If a decision cannot survive in writing, it is not ready for a meeting.
That sentence alone would eliminate a large amount of security drag.
The written version does not need to be long. In fact, it should be short. A good security decision memo can fit on one page:
-
Question: What are we deciding?
-
Context: Why now? What changed?
-
Options: What are the real choices?
-
Recommendation: What should we do?
-
Tradeoffs: What risk are we accepting or avoiding?
-
Owner: Who decides?
-
Deadline: By when?
That format forces discipline. It also aligns with what we covered earlier about advice versus execution. Advice is decision support. Execution comes after. Meetings often blur the two. Writing separates them cleanly.
A concrete example: vendor onboarding
Let’s say a business team needs to onboard a customer support vendor in 5 business days.
The meeting-based approach looks like this:
-
Intake comes in vague
-
A meeting gets scheduled
-
Security asks questions live
-
Procurement asks about contract timing
-
Privacy asks what data is involved
-
Legal asks whether the vendor is a processor
-
Engineering asks whether integration is necessary
-
Nobody has all the answers in the room
-
Follow-ups are assigned
Now compare that to an async decision model.
Before any meeting:
-
Requester fills out a short intake
-
Security assigns a risk tier
-
Privacy identifies whether personal data is in scope
-
Procurement confirms timeline
-
Security writes a recommendation:
-
Approve with restrictions
-
Approve pending contractual terms
-
Defer until missing evidence is received
-
-
Owner is tagged for final decision by a set deadline
Only if there is genuine disagreement do you hold a short meeting.
That second model is not just faster. It is calmer. It respects people’s time. It also makes the decision auditable after the fact.
Meetings create false consensus
Another reason security decisions don’t belong in meetings: meetings make disagreement look smaller than it is.
People nod. People say “makes sense”. People stay quiet because they have not fully processed the issue. Senior people interpret silence as alignment. Then, two days later, objections appear in Slack or in private messages, or when the implementation starts.
That is not because people are difficult. It is because real thinking often happens after the meeting.
Async review gives people space to read, challenge assumptions and respond with better quality. This is especially important in distributed organizations, or any team spanning time zones (which is increasingly normal).
Security leaders who still rely on synchronous consensus are usually solving for comfort, not decision quality.
What meetings are actually good for
This is the part worth being precise about. Meetings are not bad. They are just overused.
A meeting is justified when one of these is true:
-
There is a real disagreement between well-defined options
-
Stakes are high and tradeoffs are sensitive
-
There is emotional or political friction that writing alone will not resolve
-
A rapid live clarification will materially improve a written recommendation
-
An incident is unfolding and time matters more than perfect documentation
That is a much smaller category than “anything involving security”.
The better question is not “Should we have a meeting?”. It is “What exactly is the meeting for that writing cannot do better?”.
If you cannot answer that clearly, cancel the meeting.
The hidden cost of live decision-making
Live decision-making tends to produce 3 bad habits.
-
First, it favors the verbally fluent over the analytically rigorous. The person who frames fastest often shapes the outcome, even if their reasoning is incomplete.
-
Second, it compresses nuance. Security decisions often involve conditional logic, scoped assumptions or compensating controls. Meetings flatten those into broad statements like “high risk” or “not comfortable”.
-
Third, it creates weak records. Months later, nobody remembers why something was approved, restricted or deferred. The rationale lives in memory, which is where governance goes to die.
This matters more than it sounds. When customers ask why something was approved, when auditors ask how decisions are made, when incidents expose prior tradeoffs, the written record becomes the difference between maturity and improvisation.
A practical operating model: write first, meet second
Here is the operating model we recommend for most security teams.
Step 1: Require a written decision request
No vague asks. No “can we quickly discuss”. Force the question into writing.
Step 2: Publish a written recommendation
Short. Clear. No essay. One owner. Explicit tradeoffs.
Step 3: Timebox async comments
Give stakeholders a deadline. Silence after that deadline is not permanent consent, but it is not grounds for endless delay either.
Step 4: Hold a meeting only if needed
And if you do, enter the meeting with a written recommendation already on the table.
Step 5: Record the decision in writing
Not just the outcome. The rationale.
This model is not glamorous. That is exactly why it works.
Another example: product security review
A product team wants to ship a feature that stores user-uploaded documents for AI-assisted summarization.
In the meeting-driven model, everyone debates abstract risks:
-
“What about data residency?”
-
“Could prompts be retained?”
-
“Do we have customer consent?”
-
“Is this allowed under our existing policy?”
-
“Should we involve compliance?”
In the async model, the reviewer publishes:
-
What data is involved
-
Whether vendor processing occurs
-
Retention assumptions
-
Key risks
-
Recommended conditions for launch
-
Things explicitly out of scope for this release
Now the meeting, if needed, becomes much smaller: do we accept these conditions or not?
That is a real meeting. It is a decision meeting, not a discovery meeting disguised as one.
Why leaders keep overusing meetings anyway
Because meetings feel safer.
A written recommendation makes accountability visible. It gives people something concrete to challenge. It requires an owner to take a position.
A meeting, by contrast, creates plausible deniability: “We discussed it”, “There were a lot of views”, “It was a group decision”.
But security leadership is not group vagueness. It is the ability to turn messy inputs into a clear recommendation that others can act on.
That’s why the strongest security leaders are often strong writers. They reduce risk by reducing ambiguity.
What “good” looks like
When security decisions move out of meetings and into writing first, several things improve quickly: fewer recurring meetings, better stakeholder prep, faster cycle times, clearer ownership, better records for later review, less political drift, fewer misunderstandings during execution.
Most importantly, security becomes easier to work with. It stops being the team that “needs another call” and becomes the team that helps the business move with informed tradeoffs.
That is a large part of what modern security leadership should look like.
Not louder. Not busier.
Just clearer.
Meetings should confirm decisions, not create them
If every meaningful security decision only exists after people talk live, your system is too fragile.
Modern work is distributed. Attention is fragmented. The organizations that handle this well do not wait for a room to become available before they think clearly. They write, they recommend, they set deadlines and they use meetings sparingly. For friction, not for first drafts.
Security decisions do not belong in meetings because meetings are too expensive, too reactive and too easy to hide inside.
They belong in clear written recommendations, with named owners and visible tradeoffs.
Then, if needed, a meeting can do what it does best: resolve the last 10%, not muddle the first 90%.
That is how you make security calmer. And that is how you make modern work actually work.
If your team is stuck in security-by-meeting and needs a cleaner async operating model, we do scoped advisory work through Fiverr, Upwork and directly through our website.