Most security dysfunction doesn’t start with a breach.
It starts with… a meeting.
Someone flags an issue (“We should probably…”) and the room does what it always does when it feels risk: it creates motion. A new initiative. A working group. A tracker. A steering committee. A quarterly roadmap item. A “Phase 1” that somehow needs a “Phase 0” first.
By the end, you don’t have clarity. You have a project.
And the original question (the one that mattered) still isn’t answered.
This is the quiet killer of security maturity: turning answerable questions into projects. Not because people are lazy. Because uncertainty is uncomfortable, and a project is a socially acceptable way to delay committing to a decision.
If this sounds familiar, it’s the sibling of last week’s idea: Compliance Is a Snapshot, Security Is a Habit. Projects are snapshots too, especially when they’re used as a substitute for making a call.
The pattern: “We need to do something” (so we do everything)
Here’s a pattern we see in both startups and public companies:
-
A real risk shows up
-
Nobody wants to be wrong in public
-
So the team creates “process” to create safety
-
The process expands until it becomes the work
-
The risk stays unresolved longer than it should
The hardest part is that this looks like “responsible leadership”. It feels like rigor. It generates artifacts. It gives everyone something to do.
But it often avoids the one thing the organization needs most: an answer.
Advice vs. execution: what you actually need
Let’s separate two things that get mixed up constantly:
-
Advice (an answer): a decision, a tradeoff, a recommendation, a direction.
-
Execution (a project): the set of tasks required to implement that decision.
When leaders ask for “a program”, what they often mean is:
“Tell me what we should do, and why, so I can approve it”.
That is advice. Not execution.
And if you don’t explicitly name that, you end up building a project to discover an answer that you could have produced in 48 hours.
A concrete example: vendor risk that turns into theater
A business owner says: “We need to onboard this vendor next week. Security, can you do the review?”.
Security replies: “We need their SOC 2, pen test, SDLC documentation, data flow diagrams, and a meeting with their CISO”.
That might be appropriate… if you’re doing a deep assessment for a high-risk processor handling sensitive data at scale.
But most of the time, what’s actually happening is simpler:
-
The request is time-sensitive
-
The vendor is medium risk
-
The business needs a decision
-
Security feels exposed if they make the call without “enough” evidence
So the team creates a “vendor risk review project”. Which becomes a month-long ritual. Which delays the business. Which triggers escalation. Which turns security into the department of “no”.
A better outcome is often: a same-week answer, with scoped evidence and a bounded risk acceptance path if gaps remain.
Because the goal is not to collect documents. The goal is to decide.
The “Answer Brief”: your anti-chaos tool
When you need advice (not a project), you need an artifact that forces clarity.
We use a format we’ll call an Answer Brief. It’s designed to be short, decision-oriented and uncomfortable in the right way.
Answer Brief (one page, max):
-
The question (one sentence): What decision are we making?
-
Context (3 bullets): Why now? What changed? What’s constrained?
-
Options (2–3): What are the real choices?
-
Recommendation: One option, clearly stated.
-
Rationale: The 3 most important reasons.
-
Risk tradeoffs: What we’re accepting and what we’re mitigating.
-
Next steps (timeboxed): What execution looks like (if approved).
-
Owner + deadline: Who owns the decision, by when.
Notice what’s missing: “Phase 0 discovery”. The Answer Brief is the discovery, compressed into something leaders can actually use.
Another example: incident response readiness
Someone says: “We should improve our incident response plan”.
Great. But what do they mean?
This often turns into a big rewrite project. Weeks of editing. Lots of comments. The plan becomes “clean”. Everyone feels productive.
Then the next incident happens and the plan is irrelevant, because the real issue wasn’t the document. It was decision-making under stress:
-
Who is authorized to pull the plug?
-
Who talks to Legal first?
-
Do we have logging in the right place?
-
Can we actually isolate a system without breaking production?
If you need advice, the question isn’t “Should we improve the IR plan?”. It’s:
“What are the top 3 failure modes if we have a real incident next quarter, and what’s the fastest way to reduce them?”
That answer might be:
-
Do one tabletop exercise focused on escalation and comms
-
Fix two logging gaps that would make triage impossible
-
Define a single decision owner for containment
That’s not a project. That’s direction.
Why organizations love projects (even when they’re wrong)
Projects are attractive because they:
-
Spread accountability (“we’re all working on it”)
-
Create visible progress (“look at the tracker”)
-
Reduce the fear of being wrong (“we haven’t decided yet”)
-
Feel fair (“everyone gets input”)
But security doesn’t get safer because your Notion or Confluence page is prettier. It gets safer when the organization makes better decisions faster, and then executes with consistency.
A simple test: are you avoiding a decision?
If you’re about to launch a security initiative, ask these three questions:
- What decision are we delaying?
If you can’t name the decision, you’re probably building theater.
- What would “good enough” evidence look like?
If the evidence list has no stopping rule, it will expand forever.
- What’s the cost of waiting?
Security teams over-index on the cost of a wrong decision and under-index on the cost of slow decisions.
If the cost of waiting is high (revenue, customer trust, regulatory exposure), you need an answer. Even if it’s imperfect.
The “48-hour security consult” mentality
This is the shift we push teams toward:
Instead of: “Let’s start a project to figure it out”, try:
“Give me 48 hours. I’ll come back with a recommended decision, tradeoffs and a tight execution plan.”
That forces scoping, prioritization, explicit assumptions and a real owner.
It also changes how the business experiences security. You’re no longer the team that creates delays. You’re the team that creates clarity.
When you do need a project
Some problems are real projects:
-
Implementing SSO/MFA across systems
-
Re-architecting logging and detection
-
Building an SDLC security program
-
Rolling out endpoint management
-
Hardening cloud accounts across a multi-account environment
These take time. They need planning. They need milestones.
But even here, the first deliverable should still be an answer:
“What are we doing, why, and what does success look like?”
A project without a crisp answer becomes a permanent initiative with no finish line.
How to operationalize this without being annoying
If you lead security (or you’re the person everyone asks), build two habits:
Habit 1: Refuse vague asks politely
When someone says “We should improve security here”, respond with:
-
“What decision are you trying to make?”
-
“What outcome do you need by when?”
-
“What’s the risk you’re most worried about?”
This isn’t pushback. It’s leadership.
Habit 2: Default to small answers, then scale
Start with an Answer Brief. If the answer reveals a real implementation effort, then scope a project.
You earn trust by being decisive first, thorough second.
Closing thought: clarity is calm
When security becomes chaotic, it’s usually because decisions are being avoided. The organization compensates by creating motion.
Motion isn’t maturity.
Clarity is maturity. Clarity is calm. And calm security beats perfect security.
If your team is drowning in security “initiatives”, pick one and rewrite it as a single decision. Build an Answer Brief. Put a name next to the owner. Set a deadline.
Then do the simplest thing that reduces risk.
That’s how you keep security moving, without the drama.
Want to work together?
If you want help turning messy security efforts into crisp decisions (and practical execution plans), that’s the kind of work we do.
We take on small advisory engagements and scoped projects via Fiverr or Upwork, and we also work directly with teams through our website.