What a state CIO office actually buys

The office is smaller than its title

The systems with the largest technology budgets in a state government are almost never owned by the state CIO. Medicaid claims processing, unemployment insurance, child welfare case management, driver licensing, tax administration — each belongs to the line agency that runs the program, is funded in large part by a federal agency, and is approved by that federal agency before a dollar moves. The CIO office writes standards those systems must meet, often hosts them, and usually sits on the board that lets the project proceed. That is real influence. It is not the purchase order.

What the CIO office does buy with its own name on the contract is the layer underneath: the network, identity and access management, endpoint and perimeter security, the data center or the cloud footprint replacing it, enterprise agreements for productivity and infrastructure, the public-facing web platform, the cross-agency data-sharing plumbing, and the governance apparatus now forming around AI. Those are substantial budgets with real contracts attached. They are simply a different list than the one most vendors assume when they ask for a meeting with the state CIO.

The practical consequence is that "we met with the state CIO" is not a qualified pipeline entry until you can name which list your product sits on. If it is the enterprise layer, the CIO office may hold the money and the paper. If it is a program system, the CIO office is a reviewer and a standards body, and the person who signs works somewhere else — possibly in a federal regional office two states away.

The 2026 priority list, from the source

NASCIO, the association of state chief information officers, publishes a ranked list of State CIO Top Ten Policy and Technology Priorities compiled from its members. For 2026, artificial intelligence took the top position for the first time. Cybersecurity, which had held first place for twelve consecutive years, moved to second. The full ranked list:

• 1. Artificial intelligence — governance, policies, use cases, security, privacy, workforce skills, data quality, ethical use, adoption.
• 2. Cybersecurity and risk management — governance, budget, frameworks, data protection, insider threat, third-party risk, whole-of-state programs.
• 3. Budget, cost control, fiscal management — managing budget reduction, managing federal funding, cost avoidance under constraint.
• 4. Modernization — enhancing, renovating and replacing platforms and applications; business process improvement; governance.
• 5. Digital government and digital services — service frameworks, the portal, identity, privacy, cross-agency collaboration.
• 6. Accessibility — accessible services, sites, communications and tools, including accessibility in state procurement and compliance with DOJ rules.
• 7. Identity and access management — resident digital services, workforce access, authentication, credentialing, digital standards.
• 8. Data management and analytics — governance, architecture, strategy, business intelligence, predictive analytics.
• 9. Consolidation and optimization — centralizing services, operations, infrastructure and data centers; enterprise thinking.
• 10. Cloud services — strategy, service and deployment model selection, governance, service management, security, procurement.

Read that list carefully and a pattern shows up. Four of the ten entries — accessibility, identity, consolidation, cloud — are enterprise services the CIO office genuinely owns end to end. Three — AI, cybersecurity, data management — are governance functions where the CIO writes the rules that other people's budgets must follow. Two — modernization and digital services — are shared, with the CIO providing the platform and the agency providing the program logic and the money. One, budget and fiscal management, is a constraint rather than a purchase, and it explains more vendor rejections than any technical objection.

A priority list is not a shopping list. It tells you what the office is being measured on, which tells you what argument will get attention. It does not tell you whose signature block appears on the contract. For that, three questions.

Question one: whose money is it

Follow the funding before you follow the org chart. In state government, the source of the money determines the approval chain, the contract terms, and often the architecture — before any vendor is in the room.

State health and human services systems are the clearest case. Under 42 CFR 433.112, federal financial participation is available at the 90 percent rate for the design, development, installation or enhancement of a state's mechanized claims processing and information retrieval system, provided CMS approves an Advance Planning Document before the funds are spent. Under 42 CFR 433.116, operation of an approved system draws 75 percent. When the federal government pays nine of every ten development dollars, the federal government sets the conditions.

Those conditions are not soft preferences. The 90 percent rate in 433.112 is conditioned on, among other things, the state retaining ownership of software developed under the match, the federal government receiving a royalty-free non-exclusive license to use that software, the use of modular and flexible development approaches with open interfaces, alignment to MITA maturity standards, promotion of sharing and reuse of Medicaid technology across states, and compliance with health IT, HIPAA, accessibility and civil rights standards. A vendor who arrives proposing a proprietary monolith with restrictive license terms is not negotiating from a weak position. That vendor is proposing something the state cannot legally fund at the rate it has budgeted.

45 CFR Part 95, Subpart F sets the review thresholds that govern the schedule. For enhanced-match requests, planning and implementation APDs require prior approval regardless of cost, and acquisition documents and contracts require prior approval once the contract is anticipated to exceed $500,000; contract amendments crossing $500,000, or time extensions of more than 60 days, come back for approval too. For regular-match requests the lines sit higher: $5,000,000 or more in combined federal and state funds for planning and implementation APDs, $6,000,000 or more for competitive software application development acquisitions, $1,000,000 for noncompetitive ones, and $20,000,000 competitive or $1,000,000 noncompetitive for hardware and commercial software. Amendments that cumulatively exceed 20 percent of the base contract cost also require approval.

Those numbers have direct consequences for a vendor's plan. A 60-day time extension is a federal action, not a project-manager courtesy. A change order that walks the contract past 20 percent growth reopens a federal file. And a fixed-price schedule that assumes contract award follows selection by two weeks will miss, because a federal review window sits between them.

Question two: whose authority is it

State CIO authority has statutory edges, and they are usually written down. Virginia is a useful example because the boundary is explicit in code. Under Va. Code § 2.2-2006, the "executive branch agency" definition that scopes VITA's authority reaches agencies, boards, commissions, councils and public institutions of higher education in the executive department listed in the appropriation act — and then carves out the University of Virginia Medical Center, the Virginia Port Authority, and higher education institutions exempted under the Restructured Higher Education Financial and Administrative Operations Act. The statute also says the technology provisions are not to be construed to hamper the instruction and research missions of the institutions.

Other states draw the line in other places, but the same three categories recur outside central IT authority almost everywhere: public higher education systems, separately elected constitutional officers such as the secretary of state, attorney general and treasurer, and the legislative and judicial branches. Each of those buys technology, sometimes at significant scale, and none of them is reachable through the CIO's office. A vendor selling a research data platform to a flagship university and pitching the state CIO for the introduction is pitching someone with no authority over the buyer and, in many states, no standing to review the purchase.

The same question applies downward. County and city IT departments are separate governments with separate procurement rules, and a state contract does not automatically reach them. Some state master agreements are written so that local entities may buy from them; many are not. The word to look for in the solicitation is whether political subdivisions are named as authorized users. If they are, one award opens a whole tier of buyers. If they are not, each county is its own sale. Our piece on county-level analytics procurement works through what changes at that level.

Question three: whose paper is it

Most state technology purchases do not happen through a fresh competitive solicitation. They happen against a contract that already exists. The vendors who look fast to a state buyer are usually not faster engineers; they are vendors who did the paperwork eighteen months earlier.

The largest of these mechanisms is NASPO ValuePoint, the cooperative purchasing program run by the National Association of State Procurement Officials. It operates on a lead state model: one state runs the sourcing and awards a master agreement on behalf of the others, and participating states join through a participating addendum that adapts the master terms to that state's law. NASPO ValuePoint reports more than $21 billion in annual spend across more than 450 suppliers and 61 portfolios, one of which covers information technology and communications. Eligible public entities include all fifty states, the District of Columbia and the territories.

Below that sit state term schedules and state IT-specific cooperative programs, which are the same idea at one jurisdiction's scale: a pre-competed catalog that an agency can buy from with a purchase order instead of an RFP. We cover the mechanics separately in state term schedules and cooperative purchasing organizations.

There is a second reason vehicles matter more in state work than in federal work. State IT offices are frequently structured as internal service organizations that bill agencies for what they consume rather than receiving a single appropriation for everything. Minnesota IT Services publishes a rate schedule; Virginia's VITA publishes a service catalog alongside its statewide contracts. In that structure, a new purchase has to be recoverable through a rate that agencies will actually pay. A product that cannot be priced into an existing service line has a harder path than one that slots into an already-billed category, independent of how good it is.

Two gates that decide whether you are allowed to sell at all

Before evaluation criteria matter, two pass/fail gates apply in a growing number of states. Neither is about your technology.

Cloud security verification. GovRAMP — the state and local cloud security program that operated as StateRAMP — provides a tiered, NIST-aligned verification path for cloud service providers selling to government. Its tiers run from a Security Snapshot at roughly 40 NIST controls, through Core Verification at about 60 and Ready Verification at about 80, to Authorized and Provisional Verification at 300-plus controls. The program reports more than 70 participating government organizations, more than 1,200 member organizations on the provider side, and over 330 products in the program. Its participating governments include roughly two dozen states plus counties and cities. Some of those states have moved from participation to requirement for particular categories of cloud service. Where that has happened, an unverified provider is not a weaker bid; it is a non-responsive one.

Digital accessibility. This one now has a fixed federal deadline attached, which is why it climbed to sixth on the 2026 CIO priority list.

The operational read for a vendor is straightforward. If your product renders anything a member of the public will see, you need a current accessibility conformance report against WCAG 2.1 Level AA for the exact version you would deliver, not for a predecessor release and not for a component library you happen to use. State buyers are being asked to prove conformance for content delivered through contractors, so the request will come, and a conformance report full of "partially supports" without remediation dates reads as a liability transfer.

AI is a governance purchase before it is a technology purchase

Artificial intelligence reaching first place on the CIO priority list does not mean states are about to buy models. The priority entry itself lists governance, policies, use cases, security, privacy, workforce skills, data quality and ethical use before it gets to adoption. That ordering is the buying sequence.

The legislative picture explains the caution. The National Conference of State Legislatures reports that in 2025 all fifty states plus Puerto Rico, the Virgin Islands and the District of Columbia introduced AI-related legislation, and 38 states adopted or enacted roughly 100 measures. A CIO whose legislature passed two AI bills last session is not going to sign a generative AI deployment that cannot produce an audit trail, an inventory entry, and a documented human review step.

What that means in a first meeting: bring the governance artifacts, not the demo. Model documentation, an evaluation harness with results the state can rerun, a logging design that answers "who saw what and why," a data-handling statement, and a plan for the state's own inventory obligations will move further than accuracy claims. We wrote separately on state AI policy and what it means for vendors, and the same discipline shows up in federal work in evaluation harnesses that survive a review.

Operator states and broker states

State central IT organizations come in two broad shapes, and the shape changes who your customer is.

Operator states run their own infrastructure and employ their own engineers. The CIO office builds, hosts and supports. In an operator state the CIO office is a direct buyer of tools, platforms and specialized engineering capacity, and a vendor sells to it the way a vendor sells to any technical organization: capability, integration, price.

Broker states buy managed services from a small number of large suppliers and spend their internal effort on governance, integration and vendor management. Georgia's Technology Authority, for instance, delivers shared IT services to state and local entities rather than operating everything in house. In a broker state, the CIO office is a buyer of contracts more than a buyer of technology, and a new entrant's realistic route is through an incumbent supplier as a subcontractor, at least for the first engagement. That is not a consolation prize; it is the correct opening move, and it is how a firm builds the past performance that makes a prime bid credible later. Our piece on subcontracting on a state data platform award covers how those arrangements are structured.

Telling the two apart takes about twenty minutes. Read the state IT agency's most recent strategic plan and its published service catalog. If the catalog reads like a list of things the agency does, it is an operator. If it reads like a list of things the agency arranges, it is a broker. Then check the state's transparency or contract search portal for the largest active IT contracts. In a broker state, three or four names carry most of the dollars, and those names are your real buying center.

What the office can sign quickly, and what it cannot

Speed in state government is a function of dollar thresholds and existing paper, not urgency. Every state sets a small purchase threshold below which a competitive solicitation is not required, and those thresholds vary widely; we track the range in small purchase thresholds by state. Below the line, a CIO office can buy a scoped assessment, a pilot, or a fixed-scope engineering task on a purchase order in weeks. Above the line, the clock resets to a solicitation cycle measured in quarters.

This is why the first sale into a state is usually not the system. It is a bounded piece of work that produces something the office can show: an inventory, a data quality assessment, an accessibility remediation plan, a working evaluation of a capability against the state's own data. That engagement is small enough to buy quickly, real enough to establish performance, and specific enough that the follow-on scope writes itself.

What to have ready before the first meeting

• A named budget line or a vehicle you already hold — "we would be a new procurement" is an answer that ends the conversation.
• An accessibility conformance report against WCAG 2.1 Level AA for the exact release you would deliver, with remediation dates on anything short of full support.
• A cloud security package matched to the state's tier — GovRAMP status where the state requires it, or a dated plan to reach it.
• Written positions on data ownership, source code, and exit — especially if federal match money is involved, where state ownership and a federal license are conditions of funding.
• A price that fits an existing rate line or a small purchase threshold, plus the full-scope price behind it.
• The name of the federal program office if any part of the money is federal, and the current APD status of the project.
• Completed registration in the state's e-procurement system, not started — see e-procurement systems by state.

Where this is genuinely unsettled

Three things are moving, and it is more useful to say so than to pretend the map is finished.

The first is federal funding stability. Managing federal funding appears inside the third-ranked 2026 priority alongside budget reduction and inadequate funding, which is unusual language for a priority list and reflects real uncertainty about program dollars that state IT plans depend on. Projects sized against a federal match assume the match holds for the life of the build.

The second is AI procurement language. There is no national standard for how a state buys an AI system, and 38 states legislating in a single year means the contract clauses are being written state by state, in parallel, with different definitions of the same words. A vendor should expect the terms to differ materially between two neighboring states and should not assume a clause accepted in one is portable.

The third is the reach of cloud security verification. GovRAMP participation is broad but requirement is uneven, and some states run their own state-branded programs with their own reciprocity rules. Verify what a specific state requires for a specific service category rather than assuming a general answer.

Bottom line

The state CIO office is a real buyer with a specific catalog: security, identity, network, cloud, the public digital platform, data infrastructure, and now AI governance. It is also a gatekeeper for a much larger set of purchases it does not fund, where the money is federal, the approval chain runs to a federal component, and the architecture is constrained by regulation before anyone writes a requirement. Vendors who ask the three questions early — whose money, whose authority, whose paper — spend their time in front of people who can actually sign. Vendors who do not spend a year building a relationship with a reviewer.

Frequently asked questions