How we work · Solutions engineering · Architecture calls

When the call gets technical, a CISSP-credentialed engineer joins it. Not a sales rep.

Most sourcing introductions end up as "here's a vendor account executive — good luck." Our model is different. Your second call isn't with a vendor rep. It's with a certified solutions engineer from our advisor network who has walked the architecture conversation hundreds of times across the supplier portfolio. They work the call, translate buyer requirements into vendor-quotable RFPs, and push back on pricing that doesn't reflect your actual posture. That's the difference between a sourcing conversation and a buying experience.

The two-call structure, explained.

A typical sourcing engagement through CISO Marketplace involves two scheduled calls. The first is yours to drive — we listen, ask clarifying questions, and lock down the actual problem. The second is where the technical depth arrives.

Call 1Discovery Call 2Solutions Architecture
Who's on it CISO Marketplace Lead CISO Marketplace Lead + CISSP-credentialed solutions engineer from our advisor network
What gets discussed Your environment, your gaps, your buying timeline, your real constraints — not the wish list Architecture options, vendor shortlist refinement, technical questions you'd ask a vendor SE — answered honestly because the engineer isn't selling for one vendor
What you leave with Confirmed brief, written gap summary, supplier shortlist Architecture sketch, vendor-specific quote requests sent, expected proposal timeline
Duration 30–45 minutes 45–60 minutes (depends on category depth)
When Within 24–48 hours of brief submission Day 2–3 once your inputs and the engineer's prep are aligned

Members get a dedicated CISO Marketplace engineer.

Standard sourcing routes your brief to the advisor network. CISO Marketplace members get a dedicated engineer — same credentials, same advisor network depth, but a consistent point of contact who knows your environment across engagements. Priority queue, deeper briefing, faster architecture turnaround.

Who's on the architecture call.

The solutions engineers in our advisor network are not vendor employees. They don't get paid to push a specific product. They've spent careers — most have 15+ years — doing channel engineering across the full supplier portfolio. They've seen the same architecture problem solved three ways across three vendors. They have opinions on which one fits your situation. That's the value: depth across the market, not advocacy for a single line.

Credentials

CISSP, CCIE, CCSP, CCSK

The advisor network is credentialed deep — most engineers hold CISSP plus vendor-specific certifications across the categories they work (Cisco, Palo Alto, Fortinet, Microsoft, AWS, Google Cloud, and more). They've earned the credentials the hard way and re-cert regularly.

Experience

15–25+ years in channel engineering

These aren't entry-level technicians reading a script. The average engineer in our advisor network has been doing pre-sales architecture across security and infrastructure for 15 years or more — with a meaningful cohort over 25.

Scope

Full advisor network portfolio

The advisor network covers the vetted supplier catalog — security, networking, communications, cloud, observability, contact center, physical security, and connectivity. If it's in the catalog, an engineer has done architecture work on it.

Operational model

They act on our behalf, not the vendor's

The engineer on your call works for the sourcing outcome. They're not paid by the vendor whose product you eventually buy. Their alignment is with you — right architecture, fairly priced, delivered on time.

What the engineer actually does on the call.

Technical environment clarification
Technical environment clarificationWhat does your edge actually look like. What's your identity layer. What's the current backup posture. The questions a vendor SE would ask — answered before the vendor gets the brief, so you don't repeat yourself five times across five RFPs.
Architecture options walk-through
Architecture options walk-throughFor most categories there are 3–4 architecturally distinct ways to solve the same problem. The engineer walks them with you — single-vendor SASE vs unified SD-WAN + SSE vs Cisco-stack standardization, for example. You decide the architecture path before vendor proposals arrive.
Vendor shortlist refinement
Vendor shortlist refinementYour brief produced a 3–5 supplier shortlist. The engineer refines it based on the architecture conversation — pulling vendors that don't fit, suggesting alternates the routing didn't surface, weighting the priority order.
RFP / quote request preparation
RFP / quote request preparationVendor proposals only get useful when the request is precise. The engineer translates the conversation into vendor-quotable specifications — throughput numbers, user counts, identity integration requirements, compliance frameworks, geographic scope — so each vendor returns an apples-to-apples proposal.
Pricing reality check
Pricing reality checkWhen proposals come back, the engineer knows what real pricing looks like across the portfolio. They push back on inflated quotes, surface discount levers, and flag when a vendor is sandbagging volume tiers.

Where the engineer adds the most value.

Architecture decisions

"Should we go single-vendor or best-of-breed?"

The highest-leverage conversation in any sourcing engagement. The engineer has watched both paths play out across hundreds of customers. They'll surface the tradeoffs in your specific context — operational headcount, existing investments, integration complexity, vendor lock-in tolerance.

Compliance translation

"What does CMMC L2 actually require us to buy?"

Framework requirements turn into vendor selection in non-obvious ways. The engineer translates compliance language into architecture decisions, then into supplier shortlists, then into RFP specifications. Three translations most buyers do themselves badly.

Cost rationalization

"Are we paying market for this renewal?"

If you're renewing existing infrastructure, the engineer's read on current market pricing across the full advisor network is direct ammunition. They've seen the deals that closed last quarter. You haven't.

What the engineer is not.

Worth being explicit about scope — the right expectation makes the engagement work.

They are

A pre-sales architect on your side

  • Vendor-agnostic across the portfolio
  • Architecture-fluent and credentialed (CISSP, CCIE, CCSP)
  • Aligned with the sourcing outcome, not any single deal
  • Available for the architecture call and follow-up clarification
  • Often stay involved through implementation as an advisor
They are not

A vendor's account executive

  • Not paid by any single vendor
  • Not measured on quota for one product line
  • Not the person who tells you "trust me, ours is the right choice"
  • Not the person who disappears after the deal closes
  • Not under pressure to close this quarter
Also not

An implementation engineer or MSP

  • Not the people who deploy the solution day-of
  • Not your post-sale TAM or CSM
  • Not a replacement for vendor professional services
  • They scope and source — implementation lives with the vendor or your integrator
  • Different role, different deliverable, different SLA

Why this model actually works.

The economic structure is the reason. Solutions engineers in our advisor network earn their living off long-term sourcing relationships across hundreds of buyers — not commission on a single deal. That structurally aligns their incentives with the right architecture, not the most expensive product. When you talk to a vendor SE, you're talking to someone whose comp depends on selling you their product. When you talk to one of our engineers, you're talking to someone whose comp depends on you coming back next year. That's the difference — it's not a marketing claim, it's how the math works.

One brief. Then a real architecture conversation with a real engineer.

Start a sourcing brief