I've spent the last two years sitting in on three SecOps builds at companies bringing on their first or second security hire. 800 to 4,500 employees, all post-Series B, all standing up formal detection for the first time.
What I've watched, every time, is that culture is not the values statement that lands on the wiki in month three. It's the trade-off behavior the first hire reveals in their first 90 days, and that behavior compounds for years.
Most writing on security culture treats it as awareness training or values rhetoric, both of which miss the actual variable. Culture is observable behavior under pressure. Whether an analyst surfaces a missed detection or buries it, whether the detection engineer documents blind spots or writes around them, whether the post-incident review feels like game film or a courtroom.
If you're the first or second security leader at your company, you don't inherit any of this. You build it, or it builds itself into the thing you'll spend years undoing.
In brief:
- Security culture is observable behavior under trade-off pressure, not a values statement, training program, or HR initiative. Measure three to five specific behaviors, not attitudes.
- Structural decisions, including reporting line, manager alignment between operations and engineering, and on-call design, predict culture more reliably than any communications program.
- Two rituals compound: blameless post-incident reviews that ship real detection changes, and detection-as-code workflows with version control and peer review.
- Alert fatigue and burnout are detection engineering and operational design failures, not staffing problems. Adding headcount to a broken queue tells the team leadership doesn't understand the work.
What security culture actually is in 2026
The textbook frames security culture as shared attitudes and values toward security across an organization. That definition treats culture as something the security team broadcasts outward rather than something the team itself enacts inward, and it gives you no way to measure whether the culture is healthy except by surveying attitudes that are mostly downstream of behaviors.
What I'd push past is the framing. Security culture inside a SecOps function is the team's behavior when speed and security collide, when accuracy and politeness collide, and when ownership and convenience collide. Three to five observable behaviors tell you more about culture than any survey.
Whether postmortems ask "how was this possible?" or "who did this?" Whether new detections deploy with peer review and version control. Whether false positives get tracked as bugs or accepted as the cost of doing business. The job of the first or second security leader is to identify those behaviors and design for them.
Culture is behavior, not a values statement on the wiki
The framing that culture equals observable behavior isn't mine. Anton Chuvakin has been making a version of it for years. His definition of a modern SOC is "a relentless drive to D&R automation powered by a rapid and thus effective feedback loop and engineering-led mentality." The word "mentality" is doing real work there. It's a claim about what your analysts believe they are, before it's a claim about an operating model.
For the first security hire, the job description you write is the first cultural artifact. I tell every founder I work with: don't screen for "culture fit."
Write the role to reflect the team you want to build. The detection engineer's job, done well, spans IT and asset inventory work, alert experience design for the SOC, and automated hunting and containment for incident response (IR).
Naming that breadth in the job description tells the candidate what the team values before they walk in the door. Most of the early-stage JDs I've reviewed describe a SOC analyst, then wonder why the resulting team has SOC-analyst behaviors.
How engineers treat identity and secrets tells you everything
The way a team handles credentials, break-glass accounts, and access exceptions is the clearest cultural signal available to a new security leader. Mature teams automate secrets rotation and treat break-glass as emergency-only, monitored, rotated after use.
When "break glass" becomes a synonym for "the admin account we use on Tuesdays," the emergency control has been normalized into routine access, not because anyone decided to normalize it but because normal provisioning was never fixed and the gap never got treated as technical debt worth addressing.
The same diagnostic applies to how incidents get run. At one of the companies I worked with, engineering teams routinely attempted containment before paging SecOps. The CISO read this as a process gap. It was actually a history of incident reviews that engineers experienced as punitive.
The Google SRE Book names the alternative: "A blamelessly written postmortem assumes that everyone involved in an incident had good intentions and did the right thing with the information they had." That assumption, told and retold inside a team, shapes containment behavior more directly than any policy document about psychological safety.
Where SecOps reports is a cultural decision disguised as an org chart
The reporting line is the single highest-leverage cultural decision a first security leader makes, and it usually gets made for them. MITRE's 11 Strategies of a World-Class Cybersecurity Operations Center puts the structural requirement plainly: operations and engineering must report to the same leader, and that leader must have authority over tool budget and resource allocation.
When detection engineers and SOC analysts answer to different functions, the feedback loop between detection production and detection consumption breaks regardless of the individuals involved.
Across the builds I've watched, the reporting line shapes which behaviors the team can sustain. Under IT, SecOps fights for every dollar against help desk and infrastructure priorities. Under engineering, the team gets closer to the development lifecycle but is treated as a service function. Under risk, the team gains board visibility but loses operational authority. None of these are fatal.
Each one shapes the team's daily experience and the cultural patterns that can hold. The SANS 2025 SOC Survey, authored by Christopher Crowley, found 42% of SOC staff don't know the SOC's budget. That's a structural indicator that the security leader has limited visibility into the resources shaping their team's day. If your leader doesn't see the budget, neither do you.
On-call design is culture, and alert fatigue is not "part of the job"
On-call design and alert fatigue are produced by operational design, not by staffing levels. The three builds I've watched all hit the same loop:
- Alert volume outpaces detection tuning
- The queue overflows
- Leadership's response is to add headcount or mandate overtime
The team reads that response as confirmation that leadership either doesn't understand the work or doesn't consider detection quality a leadership responsibility. Rising workload, 24/7 on-call rotation, limited visibility into IT, and too many alerts to chase are all symptoms of the same operational design failure, and none of them get fixed by adding headcount to a broken triage queue.
More detections are not always better. A high rule count increases analyst workload and doesn't necessarily reflect a stronger posture. The diagnostic question I'd want every team to answer is what false positive (FP) rate is acceptable for new detections and what turnaround time for tuning the team will commit to.
Chuvakin poses the same standard. Teams that name the FP standard early can defend it later, and the FP standard is the kind of artifact that anchors a healthier culture without anyone calling it culture work.
Post-incident reviews and detection PRs build culture, not policies
Two rituals compound more than any others. The first is the blameless post-incident review. The Howie process uses framing like "learning review" and "blame-aware" and assigns a single investigator who shares a calibration document with participants before the meeting, so nobody gets confronted with findings for the first time in a group setting.
The Google SRE Workbook reinforces the same standard, with examples of leading-question framings to avoid and an explicit emphasis on assigning follow-up actions to systems rather than people. The cultural mechanism that actually matters in either framework is whether someone in the room has the standing and willingness to redirect blame language in real time, including when it comes from senior leadership.
I've sat in two postmortems in the last 18 months where the VP redirected a leading question that would have put a recipient on the defensive, and both teams have noticeably stronger detection programs now in ways the redirection itself can take credit for.
The second ritual is treating detection engineering as product work. Google Chronicle's modern detection engineering workflow documents version control, pull request review, and automated deployment as a normal practice. Detection logic mapped to MITRE ATT&CK, refined to remove false positives before deployment, validated against testing data, and shipped with triage and investigation guidance attached.
Teams that adopt these mechanics inherit the cultural artifacts of software engineering: accountability, iteration, and feedback loops. The teams I've watched try to skip the engineering scaffolding and bolt on the culture later have not pulled it off.
Celebrating detection wins counteracts the asymmetry of failure
Security operations work produces visible failures and invisible wins. A prevented breach generates no ticket, no escalation, no executive notification. Without an explicit team norm, the team's lived experience defaults to "we mostly hear about what went wrong."
Naming "take the win" as a norm, and writing it into the team's cadence as a weekly highlights post showing real detection catches, counteracts the asymmetry deliberately. I tell every first security leader to put one of those highlights in front of executive leadership monthly. The team needs the loop closed, and leadership needs to see the work the team is otherwise doing in private.
The "assume breach" frame matters here, too, but only when it's operationalized. Treating assume-breach as a slide title gets you neither the detections nor the culture. The inversion that actually changes team behavior is "the attacker only needs to be detected once," because it gives the team shared vocabulary for justifying post-exploitation detection coverage.
When that vocabulary is shared, the team makes consistent decisions about where to invest. When it isn't, every detection-coverage debate restarts from zero.
Awareness training and culture rhetoric won't save an understaffed SOC
The most common failure mode I see is investing in surface-level culture efforts while leaving the structural conditions untouched. Security Magazine reports that half of SOC teams say they're understaffed, with burnout running 32 points higher among those who feel understaffed (79%) versus those who don't (47%). Splunk's 2025 State of Security report found 46% of respondents spend more time configuring and troubleshooting tools than investigating and mitigating threats.
Launch a team newsletter or a phishing simulation program while the SOC runs at partial coverage, and analysts work mandatory on-call rotations, and the culture initiative actively damages trust because the team reads it as theater.
Delegating culture to HR compounds the problem. NIST's retention research flags manager disconnection as a barrier to participation in development opportunities and names insufficient training and development as a retention factor. HR wellness programs don't touch the operational conditions that create the pressure.
When culture ownership sits with the security leader, the levers are specific: FP rate reduction, analyst time allocated for detection engineering, escalation path clarity, and leadership visibility into queue depth. Those levers, pulled consistently, change how the work feels for the people doing it.
The first 90 days set the trajectory
The sequencing matters. Chuvakin's principle is the right one: SOC is first a team, next a process, and then uses technology. Ryan McGeehan, formerly Head of Security at Coinbase and Facebook, argues in his post on prioritizing detection engineering that the discipline does not self-organize out of SOC alert-handling. It requires a visible, named resource allocation decision in the first months.
What I'd add is that the absence of that decision is itself a cultural signal. It tells the team that detection is what analysts do when they have spare time, which is also what playbook-writing is, what tuning is, what hunt design is.
Establishing a named, documented lifecycle for detection work in the first 90 days does the structural and the cultural work at once, because the specific names matter less than the act of naming.
My read on the next two years is that a strong security culture compounds from four specific behaviors: naming the detection lifecycle early, defending the FP standard, redirecting blame language in real time, and treating the on-call queue as an engineering problem.
The first security leaders who do all four end up running the teams everyone else tries to recruit from. That compounding is what culture actually means, well before anyone writes it down on the wiki.
Frequently asked questions about security culture
How do you measure security culture in a SOC?
Identify three to five observable behaviors and track them directly. Are postmortems asking "how could this be possible?" or "who did this?" Are detection rules deployed with peer review and version control, or pushed ad hoc? Are false positives tracked and treated as bugs, or accepted as the cost of doing business?
Does where SecOps reports in the org chart actually affect culture?
Yes, more than most security leaders are told. MITRE's 11 Strategies of a World-Class Cybersecurity Operations Center requires that operations and engineering report to the same leader with authority over the tool budget.
When detection engineers and SOC analysts answer to different functions, the feedback loop between detection production and consumption breaks down structurally, regardless of the quality of the individuals. Reporting under IT, engineering, or risk shapes which behaviors your team can sustain.
What's the difference between security culture and security awareness training?
Awareness training changes end-user behavior around phishing and password hygiene. Security culture inside a SOC is shaped by whether analysts trust their detections, whether escalations are taken seriously, whether they have agency over detection quality, and whether leadership understands the operational reality.
How do you build a security culture from scratch as the first security hire?
Start with the team, then process, then technology. Anton Chuvakin's sequencing is the right one. Write your first job description as a cultural manifesto, not a skills checklist. Establish a named detection lifecycle with shared vocabulary in the first 90 days.
Make a visible resource allocation decision that signals detection engineering is a first-class function. Ryan McGeehan argues it doesn't self-organize out of SOC operations and requires deliberate prioritization.