Angela L. Martin · SLED Playbook

Splunk in a Public-Sector Territory: How the Team Deploys It

Platform motion

Public sector CIOs and CISOs do not buy observability. They buy downtime prevention, service reliability, compliance evidence and cyber resilience.

The three plays

Play Buyer Pain they feel What the network adds What the proof of value must prove
Whole-of-state cyber, Splunk Enterprise Security as the security information and event management layer State security chief, agency security leads, security operations managers Ransomware exposure, blind spots between agencies, counties with no security operations team Switch, wireless, firewall and identity telemetry from Catalyst, Meraki, Secure Access, Duo and ISE, plus enforcement points the platform can act through Correlation across agency network and identity data, and detection-to-containment time on two written scenarios
Citizen-service reliability, Splunk Observability with ThousandEyes State CIO, application owners, digital services teams A benefits portal slows down and three teams point at each other for a week Network path and application telemetry in one view, so the outage is one conversation, not three Mean time to identify on one named citizen service, before and during
Compliance and audit, retained logs and framework reporting Security chief, audit owners, research and clinical IT Framework reporting done by hand, sprawl across monitoring tools Enterprise Agreement consolidation: fewer contracts, one renewal, lower licensing cost An audit-ready report from live data for one named framework

Discovery rule: name the service, the framework or the ransomware scenario before saying the product name. If the rep cannot, the deal is not qualified and the engineer's time is not available.

My conviction is that the sellers who lead with the data platform will carry the year, because a networking refresh alone does not move a territory number. Here is how I would deploy that motion, and where the systems engineer leads it.

Where the SE leads. The systems engineer owns the data architecture: which sources feed the platform, how they are onboarded, what the ingest costs, and the on-premises answer for data that cannot leave the state. The engineer writes the technical half of the proof-of-value criteria, scopes the hours and sets the end date. My side is the buyer, the vehicle and the paper.

Two motions

Installed base Greenfield
Entry point The network already makes the signal. Start from telemetry the customer owns and ask the engineer where it goes today A funded mandate or a public failure: a Zero Trust directive, a portal outage, an audit finding
First conversation Engineer-run data-source inventory: what logs exist, which tool holds them, what it costs, when it renews Diagnostic call with the security or digital-services owner, engineer in the room, not a briefing
Proof-of-value shape Two or three sources the customer controls, one use case, a hard stop the engineer sets Two or three metrics the mandate cares about, agreed with the Economic Buyer before data moves
Installed base Greenfield Telemetry we already own Data-source inventory Consolidation into an EA Funded mandate or failure Diagnostic conversation Mandate-shaped scope sources + renewal date metrics agreed in writing Dual-key POV gate same gate, both motions Scoped POV hard end date
The two motions enter through different doors and take different proof-of-value shapes, and both arrive at the same dual-key gate where the systems engineer's signature is required.

Installed base is where the first revenue comes from, because the telemetry, the relationship and the paper already exist. Greenfield builds the back half of the year. Neither motion lets a refresh close without a platform conversation on record.

The telemetry flow

Cisco telemetry Catalyst and Meraki Firewalls Identity: Duo, ISE Cloud and apps M E L T Splunk machine data engine Whole-of-state cyber Enterprise Security Citizen-service reliability Observability, ThousandEyes Compliance and audit framework reporting SE owns architecture and POV criteria AE owns buyer, vehicle, procurement
Network, identity and application sources flow as metrics, events, logs and traces into the platform and out as three buyer outcomes, with the systems engineer owning the architecture band in the middle.

This is why the engineer leads the technical conversation rather than joining late. Every source on the left is a decision about volume, retention and cost, and that is what a security leader means by expensive.

How a pod runs a cycle

Step Who owns it
Data-source inventory Engineer, with the rep present for the cost numbers
Diagnostic or Economic Buyer meeting Rep leads; engineer takes the architecture question that always comes
Written success criteria Engineer writes the technical half; rep gets the buyer on record that meeting them triggers procurement
Dual-key gate Engineering leader and me, co-signed; either key can hold it shut
Scoped proof of value Engineer owns scope, staffing, end date. The data platform specialist joins at discovery, with their own leader's agreement on the time. The vehicle is named before it starts
Debrief after every joint call Five minutes, both directions, logged on the opportunity
Adoption after signature Engineer drives the first sources live; expansion follows technical trust

Post-sale engineering time is planned in the account plan, sized by the SE leader, and counted in the same capacity view as proofs of value, so it is never borrowed from the POV queue.

Leading indicators for a data-platform motion

Indicator What it tells me
New platform-attached opportunities per rep Whether the attach motion is real
First-time security or digital-services executive meetings Whether we reach the buyer who funds the platform, not only the network director
Data-source inventories completed Whether the engineer-led entry motion has started
Scoped versus qualified proofs of value Whether engineering capacity is protected
Renewals carrying a platform attach Whether the renewal trap is closed, and whether partners carry the long tail

Thresholds are set against the region's baseline in the first 30 days, not imported from another territory.

Risks I manage in the open

Risk How it shows up What I do
Ingest cost fear The security leader has heard the pricing is complex at scale Lead with the outcome and the consolidation math, engineer in the cost conversation early
Incumbent security platform The agency runs another product with years of content on it No rip and replace. Lead with the telemetry the incumbent cannot see, and time the conversation to its renewal
Overlay friction Rep and specialist fumble the handoff or compete for the account Named pod roles from discovery, the debrief after every joint call, and I own escalation
Science-project proofs of value Open-ended trials that eat engineering weeks and never reach procurement The dual-key gate every time. The engineering key cannot be overridden. If we disagree, the proof of value stays blocked and goes to both our leaders. A proof of value that starts without both keys is a miss on me, written up and counted.
Sovereignty constraints Mission data that cannot move to a public cloud The hybrid and on-premises design is the conversation, and the engineer owns that depth

What I would learn first

  1. The real installed base: which agencies already run the platform, at what scale, and who owns it.
  2. Which incumbent security and monitoring tools sit in each state's central IT organization, and when they renew.
  3. How the specialist overlay is staffed, and how engineers are covered against it.
  4. Which regional partners are capable on the platform, not only authorized.
  5. Which reps have sold software rather than hardware, and what each needs from engineering to land a first attach.

State fiscal years close on 30 June, so anything riding on state money is on a vehicle before spring ends. That deadline is why the engineer's scoping discipline matters more than any one rep's enthusiasm.