GRC Hit 14.8% of Cyber Postings. Only 91 US Profiles List OPA.

If you're a CISO or security recruiter building a 2027 plan, CyberSN's headline looks grim: the fewest US cyber postings in four years. The harder problem sits inside that number. The share of demand that did grow went to GRC, and the engineers who can actually deliver modern GRC barely show up in a title search.

The engineers who turn controls into code are a small group, and almost none of them have "GRC" in their job title.

What do the 2026 cyber hiring numbers actually say?

US employers posted 235,786 cybersecurity jobs from January through September 2026. That's the lowest total for those months in the four years CyberSN has tracked it, and 26.4% below the 320,210 posted in the same months of 2025.

235,786

The 26.4% drop says as much about 2025 as it does about 2026. Last year was unusually strong. Against 2024, the gap is only about 4%. So the headline "cyber jobs collapse" overstates things. Total hiring is back near 2024 levels, and inside that total, a different kind of person is being hired.

That matters for headcount planning. A 4% drop doesn't justify a freeze. A shift in mix does justify changing which roles you open.

Where did cyber hiring demand move?

Demand moved from defense to governance, risk and compliance (GRC). Since 2023, GRC's share of postings has grown from 9.4% to 14.8%, and defense has fallen from 47.1% to 41.5%.

The CISO line is the noisy one. Deidre Diamond, CEO of CyberSN, said the swings "may have more to do with disruption across the C-suite than a fundamental decline in the need for security leaders." Read it as churn at the top, not a signal about the GRC roles underneath.

Why the GRC surge is not a GRC engineer surge

Most of the GRC growth comes from lawyers, not engineers. CyberSN reports that much of the gain came from privacy and cybersecurity attorneys, the only one of the ten largest role categories to post more listings this year than last.

This is where a lot of 2027 plans will go wrong. A CISO reads "GRC up," opens a "GRC Analyst" req, and ends up competing for spreadsheet-and-questionnaire people in the attorney-and-analyst part of the market. The req may fill. It just doesn't fix the problem.

Two definitions help here:

• A GRC engineer is a security engineer who turns compliance controls into code, automated checks, and machine-readable evidence, so audits don't depend on screenshots.
• Compliance as code means writing control requirements as version-controlled, testable policies that run continuously against real infrastructure.

Regulators are pushing toward the engineer version. FedRAMP 20x replaces annual manual assessments with 43 automated Key Security Indicators. Nobody produces automated indicators by filling in a spreadsheet. Somebody has to write the code that queries the cloud, evaluates the policy, and emits the evidence.

The leverage is high when you find the right people. On the GRC Engineer podcast, Docker described how two GRC engineers completely rebuilt a GRC program in six months.

How big is the US pool of compliance-as-code engineers?

It's tiny. In Refolk's index of professional profiles, only 91 US people list Open Policy Agent as a skill. Compare that with 607 people titled Compliance, Security Compliance or GRC Engineer, and 2,206 in SOC and detection roles.

The two derived rows assume the 14.8% and 41.5% shares apply to the 2026 total. Treat them as rough sizing, not exact counts.

24:1

The ratios are the useful part:

• SecOps to OPA: 24 to 1
• Compliance-titled to OPA: 6.7 to 1
• GRC-share postings to OPA profiles: roughly 380 to 1

That last ratio isn't a fair comparison, because the postings include attorneys and analysts. It still tells you how this goes: if your req needs someone who writes Rego, you're fishing in a pond, not a market.

Why searching "GRC Engineer" on LinkedIn fails

A title search misses the people you want, because they don't have GRC titles. In Refolk's index, every top title among the 91 OPA profiles is an engineering title, and the 607 "Compliance Engineer" profiles lean toward product and regulatory compliance, not security.

The top titles among US OPA profiles:

1. Software Engineer
2. Senior Software Engineer
3. Security Engineer
4. Senior SRE / DevSecOps
5. Distinguished Software Engineer
6. Head of Security + Foundations Engineering

The employers make the same point. Apple, JPMorganChase and Boeing each have two, followed by Atlassian, Ramp, Meta, GEICO and CNCF Consulting. These are engineering organizations, not compliance departments.

Now look at the 607 people titled Compliance Engineer. Top employers include UL Solutions, Mitsubishi Electric, Brady and Iovance Biotherapeutics, which points to product and regulatory compliance rather than security. Only one sampled title was explicitly "Cyber GRC" (a Solutions Engineer, Cyber GRC). Palantir and the US Department of Veterans Affairs led the pool with two each.

Title and skill barely overlap in this niche. The people writing policy as code carry software, SRE and security-engineer titles, and that's what they put on their profiles, however much of their work is Rego. Boolean search on titles will hand you 607 people, most of whom aren't doing security work at all.

Compliance as code gets written by people whose title says Software Engineer. Title searches will never find them.

Why 91 is a floor, and where the real evidence lives

Treat 91 as a minimum. Profile skills are self-reported, and Rego is a niche language that few people bother to list. The real evidence of compliance-as-code work is on GitHub, which makes it the main channel for sourcing these engineers.

The tool stack named across GRC engineering writing is fairly standard:

• OPA and Rego: policy as code
• OSCAL: machine-readable control data
• Steampipe or CloudQuery: querying cloud APIs
• Prowler: cloud security checks mapped to compliance frameworks

Those tools leave fingerprints you can search for:

• .rego files in public repos
• Conftest or Gatekeeper policies
• OSCAL JSON
• Powerpipe or Steampipe benchmark mods
• Contributions to Prowler

None of these depend on what someone typed into a LinkedIn skills box. An engineer with Gatekeeper policies and OSCAL JSON in their repos has shown the skill, whatever their title says.

Doing this by hand means running GitHub code search for each signal, then matching commit authors to real people, current employers and locations. It's slow, and at a pool of about 91 you can't afford to miss anyone. This is the gap Refolk closes: you describe the person in plain English, and it searches GitHub, LinkedIn and the open web together, so a Senior SRE with Rego repos turns up even though nothing on their profile says GRC.

Where else to find GRC engineers besides LinkedIn

Besides GitHub, the best places to find GRC engineers are conference talks, the GRC Engineering Club directory, and the community around the GRC Engineering Manifesto. The community is small enough that a few names connect most of it.

Places to start:

• BSidesSF 2024: "GRC Engineering - Bringing GRC to a repository near you," by Varun Gurnaney, Staff Security Engineer and co-author of the GRC Engineering Manifesto. He also spoke at BSidesSF 2025.
• fwd:cloudsec 2025: "Introducing GRC Engineering: A New Era of AWS Compliance," by AJ Yawn.
• GRC Engineering Club directory: member profiles list OPA/Rego, OSCAL, FedRAMP and CMMC skills, next to open roles.
• grcengineering/cheatsheet on GitHub: check the contributors and the people who star and fork it.
• The GRC Engineer newsletter: weekly issues read by roughly 3,500 subscribers. Guests and contributors are a short, high-signal list.
• Ayoub Fandi: GRC Engineer at Lovable, who previously started the GRC engineering program at GitLab, and a Manifesto co-author.

Treat speakers and authors as map nodes, not targets. Who co-presented with them? Who opened issues on their repos? Who did they thank in the talk? Second-degree connections from these people are where most realistic candidates are.

Which SecOps engineers could move into GRC engineering?

Detection engineers are the best people to convert, because they already do most of the job. They write logic as code, keep it in Git, and test it against real telemetry. That's compliance as code with a different output.

The supply is there. Refolk's index counts 2,206 US people with SOC Analyst, Security Operations Engineer, Detection Engineer or SOC Engineer titles, at employers including Meta, Block, AppFolio and HCLTech. That's the part of the market losing share, falling from 47.1% to 41.5% of postings since 2023.

One security podcast put it this way: GRC and detection engineering are "solving the same problems and somehow still not working together." A detection rule asks whether something bad happened. A compliance check asks whether a control is in place. Both are queries over infrastructure state, version-controlled and tested.

Signals that separate a good convert from a pure alert-triage analyst:

1. Detection logic kept as code in Git, with tests
2. Tooling that queries cloud APIs, such as Steampipe or CloudQuery
3. Any exposure to frameworks like FedRAMP or CMMC
4. Public writing about automating evidence or reducing alert noise

Leave out analysts whose work lives entirely in a console with nothing in Git. The conversion depends on being comfortable with code, not on knowing security.

Screening 2,206 people by hand for those signals takes weeks. In Refolk, you can ask for detection engineers who also have cloud-API tooling in public repos and get back the subset worth a first call, not the whole list.

How to plan 2027 GRC headcount with these numbers

Plan for engineers, not analysts. Size the req against a pool of about 91 visible specialists, and budget for converting SecOps people rather than counting on a finished hire.

A practical sequence:

1. Write the req around outputs. "Automate evidence for 43 FedRAMP 20x KSIs" attracts the right people. "GRC Analyst" attracts questionnaire specialists and pulls you into the attorney-driven part of the market.
2. Title it as engineering. Call it Security Engineer, Compliance Automation or Staff SRE, Policy. The pool you want already has those titles.
3. Source from code first. Rego, OSCAL, Gatekeeper and Prowler contributions, then talks and the GRC Engineering Club.
4. Run a conversion track at the same time. Pick one or two detection engineers from the 2,206, pair them with a senior policy-as-code hire, and give them a framework to automate.
5. Keep the team small. Docker's two-engineer, six-month rebuild shows how far the right two people can go.

FAQ

How do I hire GRC engineers if so few list the skill?

Search by the work they've done, not by title. Look for public repos with .rego files, Conftest or Gatekeeper policies, OSCAL JSON, Steampipe or Powerpipe benchmark mods, and Prowler contributions, then match those authors to current employers. In Refolk's index, all six top titles among US OPA profiles are engineering titles, so title searches leave most of the pool out.

Are cybersecurity job postings in 2026 really down 26%?

Yes, compared with 2025: 235,786 postings in January through September 2026, against 320,210 in the same months of 2025. But 2025 was unusually strong. Against 2024, the drop is only about 4%. The bigger change is in mix, with GRC rising to 14.8% of postings and defense falling to 41.5%.

Is the GRC hiring growth mostly engineers?

No. CyberSN attributes much of GRC's gain to privacy and cybersecurity attorneys, the only one of the ten largest role categories to post more listings this year than last. Compliance-as-code engineers are a small slice of that demand, which is why a generic GRC req risks competing for the wrong group of people.

Can SOC analysts become compliance-as-code engineers?

Detection engineers can, because they already write logic as code, keep it in Git and test it against telemetry. Analysts who work only in a console with no code history are a harder conversion. Refolk's index shows 2,206 US SecOps and detection profiles, about 24 for every OPA-tagged profile, so there are enough candidates to recruit from.