Security work fails in a predictable way.

A leader asks: “Can you help us with security?”. Security replies: “Sure!”. Six weeks later, everyone is frustrated, because they were talking about two different things.

One side wanted answers: what to do, what not to do, what matters, what’s acceptable risk, what the roadmap should be, what customers should hear, what the board should see.

The other side delivered work: tickets, tools, policies, questionnaires, controls, meetings, evidence and a lot of motion.

Advice and execution are both valuable. But they are not interchangeable. And when you blur them, you get the worst outcome: lots of activity with little clarity.

This is a key thread across the earlier posts in this series:

In every case, the real failure mode is the same: the organization didn’t know whether it was buying advice or buying execution.

Let’s fix that.

Advice is decision-making. Execution is delivery.

Here’s the cleanest definition we’ve found:

  • Security advice = a recommendation that changes a decision

  • Security work = the set of actions that implements that decision

Advice ends with a clear call. Execution starts with a clear call.

If you can’t point to the decision, you probably don’t have advice. You have commentary.

If you can’t point to the deliverable, you probably don’t have execution. You have intent.

Why this gets confused (constantly)

  1. “Security” is used as a single bucket word

Business leaders say “security” and mean:

  • “Help us close deals”

  • “Help us pass SOC 2”

  • “Help us stop incidents”

  • “Help us reduce vendor risk”

  • “Help us not embarrass ourselves”

Security teams hear “security” and start listing controls, tooling and frameworks.

Both are reasonable. The mismatch is that one is asking for direction and the other is offering mechanics.

  1. Advice is uncomfortable, work is comforting

Advice requires committing to tradeoffs:

  • “We will accept this risk to move faster”

  • “We will delay this feature because it increases exposure”

  • “We will restrict vendor access even if it’s annoying”

That’s hard. Especially in public.

Execution feels safer: you can always “do more” without declaring what matters most.

But motion is not maturity. Clarity is.

  1. The organization doesn’t know what good looks like

If you don’t define the outcome, security work becomes a bottomless request:

  • “Can you review this vendor?”

  • “Can you do this assessment?”

  • “Can you write this policy?”

  • “Can you implement this tool?”

Without a decision framework, execution becomes reactive labor.

Concrete example #1: SOC 2

Advice request (what they mean):

“We need enterprise trust. What’s the minimum we should do in 90 days?”

Execution response (what often happens):

“We’ll implement policies, controls, evidence collection and run the audit.”

The gap: SOC 2 is not the goal. Trust is.

Good advice sounds like:

  • “Scope it tightly to the product customers buy.”

  • “Prioritize identity, change management, logging and incident readiness.”

  • “Accept that some controls will be manual this cycle, but build the habit.”

  • “Set expectations: SOC 2 is a signal, not a shield.”

Then execution follows: implement those controls and run the audit.

When you skip advice, you often end up SOC 2-ready on paper while operational risk stays untouched.

Concrete example #2: Vendor risk review

Advice request:

“Can we use this vendor next week without doing something dumb?”

Execution response:

“Here’s a 200-question questionnaire and a 3-week process.”

The business needed a decision. They got paperwork.

Good advice in this context is:

  • Tier the vendor

  • Request high-signal evidence

  • Decide with restrictions and compensating controls when needed

Then the work is:

  • Contract clauses

  • SSO/MFA enforcement

  • Logging and access reviews

  • Integration guardrails

Advice makes vendor risk calm. Execution makes it real.

Concrete example #3: Hiring security leadership

Advice request:

“Should we hire a CISO?”

Execution response:

“We’ll open a req and start interviewing.”

That’s a hiring motion, not an answer.

Good advice is:

  • Define which archetype you need (builder vs. operator vs. navigator)

  • Assess leverage (budget, sponsorship, decision rights)

  • Choose the right interim model (fractional vs. head of security)

  • Define 90-day outcomes

Then execution is recruiting, onboarding and enabling the leader.

The “Two-Lane” model: how to stop mixing advice and work

If you want to fix this across a company, separate security into two lanes:

Lane 1: Security Advice (Decision Support)

Outputs:

  • Answer Briefs (recommendation + tradeoffs)

  • Risk acceptance decisions

  • Product/security architecture direction

  • Exec and board narratives

  • Security positioning for customers (scope, commitments, reality)

Measures of success:

  • Decisions are made faster

  • Fewer escalations and surprises

  • Fewer “we’ll circle back” loops

  • Security becomes easier to work with

Lane 2: Security Work (Implementation)

Outputs:

  • Controls implemented

  • Tooling integrated

  • Detections created

  • Access models enforced

  • Audits executed

  • Vendor controls applied

  • Incident readiness operationalized

Measures of success:

  • Reduced exposure

  • Reduced incident frequency/impact

  • Improved detection and response times

  • Audit evidence is repeatable and non-seasonal

The lanes connect, but they are not the same.

Advice should be timeboxed and crisp. Execution should be scoped and measurable.

A practical way to write a good security request

If you’re on the business side, this single template eliminates most friction:

We need a decision on ____ by ____ because ____.

Options we’re considering are ____.

Constraints are ____.

Success looks like ____.

If you recommend ‘yes,’ we can implement ____ controls.

That forces clarity. It also makes security faster.

How security teams should respond (without becoming “the department of no”)

When you get a request, start with one question:

“Are you asking for advice or execution?”

If it’s advice, respond with an Answer Brief:

  • 2–3 options

  • Your recommendation

  • Explicit tradeoffs

  • What “good enough” looks like

If it’s execution, respond with:

  • Scope

  • Owner

  • Timeline

  • Dependencies

  • Measurable definition of done

This keeps security calm and credible.

The quiet lesson: advice is where accountability lives

Execution can be delegated. Advice can’t.

Advice is what leadership looks like:

  • Choosing what matters

  • Accepting tradeoffs

  • Setting boundaries

  • Making risk decisions visible

If a security team is drowning in “work”, it often means the organization is missing advice and trying to compensate with activity.

If you fix the advice lane, execution becomes lighter, sharper and more effective.

Closing thought: stop buying motion when you need clarity

A lot of companies don’t have a security problem. They have a decision problem.

Security advice provides the answer. Security work makes the answer real.

If you want “no drama” security, separate the lanes, name the decision, and scope the work.

That’s how security turns from a burden into a function people actually trust.

If you want help establishing an “Advice vs. Execution” operating model (intake templates, Answer Briefs, tiering, SLAs and execution roadmaps), we do scoped advisory and implementation support via Fiverr/Upwork and through our website.