Table of contents
- Key Takeaways
- What Is a Security Operating Model?
- Why Every Organization Needs a Security Operating Framework
- Core Components of a Modern Security Operating Model
- Aligning Security Strategy with Business Goals
- Cloud Security Operating Models
- Measuring Security Program Success
- Security Operating Model Best Practices
- How Orca Supports a Cloud Security Operating Model
- Frequently Asked Questions about Security Operating Models
Key Takeaways
- A security operating model is the explicit answer to two questions: who holds which decision, and how does security work actually flow between the teams that do it.
- Every organization already runs on an operating model. The only question is whether it is written down or living in the head of whoever has been there longest.
- Governance, roles and decision rights, processes, and measurement are the four load-bearing components. NIST made this a first-class discipline in 2024 when it added the GOVERN function to version 2.0 of the Cybersecurity Framework.
- Cloud pushes organizations off centralized control toward federated or embedded models, because the people making security-relevant decisions no longer sit in the security team.
- Federated models only hold if every team sees the same prioritized risk picture. Orca’s agentless platform gives platform and application teams the same context the security team has, so ownership can move without security brokering every decision.
Most teams meet their security operating model on the day something falls through it. A misconfiguration sits in a shared cloud account for three weeks. The platform team assumed the application team owned it. The application team assumed security did. Nobody was wrong, exactly, because nobody had ever written down who owned it. No security tool closes that gap, because the gap is structural.
A security operating model is the explicit answer to two questions: who decides what, and how does the work actually flow? It names who approves a production exception, which team patches a shared workload, when an incident escalates, and how anyone knows whether the program is healthy.
Every organization already has one. In most, it is implicit. It lives in the memory of whoever has been there longest, and it works right up until that person leaves or two teams both assume the other has it covered. Writing it down converts personality into structure.
This guide covers the model itself, its components, how cloud reshapes it, and how to tell whether it works.
What Is a Security Operating Model?
A security operating model is the structure that defines how an organization runs security: who holds each decision, which teams execute which controls, how work flows between them, and how the program is measured. It describes the machinery of running security rather than the technology you buy or the controls you run. A cybersecurity operating model is the same concept under a different label, and the two terms are used interchangeably.
Standards bodies now treat this as a discipline in its own right. When NIST published version 2.0 of the Cybersecurity Framework in February 2024, it added a sixth function, GOVERN, alongside Identify, Protect, Detect, Respond, and Recover.
GOVERN covers organizational context (GV.OC), risk management strategy (GV.RM), roles, responsibilities, and authorities (GV.RR), policy (GV.PO), and oversight (GV.OV). That is an operating model, described by a neutral standards body. It is also the clearest signal that governance stopped being a management afterthought and became a function.
Why Every Organization Needs a Security Operating Framework
A security operating framework earns its keep by removing ambiguity before ambiguity costs you something. When the model stays implicit, the same three failures show up, and a dashboard shows none of them.
Orphaned controls
A control has an owner in practice but not on paper. One engineer set up the quarterly access review, ran it for two years, and left. It keeps reporting green because nothing checks whether a human is still behind it. These surface late, usually during an audit or right after an incident.
Duplicated work
Two teams scan the same workloads because neither is sure the other does. The compute is cheap. The expensive part is that both sets of findings arrive on a different severity scale, so the owning team triages the disagreement instead of the risk.
Escalation by seniority
With no rule for who decides, the most senior person in the channel decides. That produces reasonable outcomes most of the time and unreasonable delay the rest, because the model is only available when that person is. Turning a bought capability into a working program depends on this wiring, which is the argument behind turning a platform into a program.
None of this is about maturity. A team can run advanced tooling and still have no answer for who signs off on an exception at 5pm on a Friday. Which capabilities to adopt, and in what order, is a separate question of cloud security program maturity.
Core Components of a Modern Security Operating Model
Four components carry the model. Governance sets who decides, roles set who is accountable, processes set how work moves, and measurement tells you whether any of it holds.
Governance and Decision Rights
Governance answers one question: who gets to decide? The test is not whether you have a steering committee. It is whether a named person can approve a production exception at 5pm on a Friday when the release is blocked and the CISO is unreachable.
Write decision rights as a short list of the decisions that actually stall, each with one accountable role and a stated fallback. Accepting a risk above threshold, approving a production exception, declaring an incident, and granting standing privileged access are usually the first four. Two accountable roles on one decision means none, because each waits for the other. Set the threshold in terms of risk exposure rather than job title, so the rule survives a reorg.
Roles and Responsibilities
Roles turn decision rights into standing accountability. ISO/IEC 27001:2022 states this plainly in Clause 5.3, which requires top management to ensure that responsibilities and authorities for information security roles are assigned and communicated within the organization. NIST CSF 2.0 says the same thing in GV.RR.
RACI matrices earn their reputation for busywork when teams build one for every task. Build one only where a control crosses a team boundary, which is where ownership actually goes missing. Shared cloud accounts, base images, CI runners, and identity infrastructure are the usual suspects.
Then make the paperwork match the system. If the application team is accountable for remediating its own workloads, role-based access control has to let that team fix things without filing a ticket with security. Accountability without the permission to act is a name on a spreadsheet.
Security Operations and the Delivery Layer
Security operations is the delivery layer of the model: the standing work that runs every day rather than the decisions that shape it. Detection and triage, incident response, vulnerability remediation, patching, and access reviews all sit here.
The operating model does not tell you how to staff this layer. Whether a security operations center runs it or a team embedded within engineering does is a resourcing choice. The model owns the boundary: which alerts the delivery layer closes itself, which it hands to a product team, and what happens when the receiving team disagrees.
Every handoff needs a named receiver and a timebox, because an alert routed to a team that never agreed to receive it ages quietly. The same applies to tooling seams: decide which alerts a SIEM forwards to whom, who answers when nobody acts, and who owns the runbook that defines the response.
Policy, Standards, and Exceptions
Policy states the rule. Standards state how to meet it. Exceptions state who may break it, for how long, and on whose authority. Most organizations get the first two right and leave the third to email, which is how a temporary exception becomes permanent.
Give every exception an owner, an expiry date, and a compensating control. An exception without an expiry is a policy change nobody approved. Encoding routine rules as policy as code with a tool such as Open Policy Agent pushes the predictable decisions into the pipeline, which leaves the exception process for cases that genuinely need judgment. The same mechanism gives you the evidence trail cloud compliance work depends on, without a separate collection exercise.
Aligning Security Strategy with Business Goals
Most security strategy documents state an intention and stop. “Enable the business to move faster” changes nothing until it changes a decision rule, an owner, or a threshold. The mechanism of alignment is that translation, and it is the only part of strategy the operating model is responsible for.
Take each business objective and ask what it implies for those three things. If the objective is shipping a regulated product in two quarters, the consequence is specific: someone can approve compliance evidence without convening a committee, and the named owner sits close enough to the work to answer in hours.
Cloud risk management sets the thresholds; the operating model names who applies them. Which risks to accept and which bets to make is a separate exercise, covered in implementing your cloud security strategy.
Cloud Security Operating Models
A cloud security operating model has to answer something the on-premises version never faced: the people making security-relevant decisions no longer work in security. A developer writing an IAM trust policy or a platform engineer publishing a Terraform module makes a call that used to belong to a review board.
The shared responsibility model divides decisions between you and your cloud provider. Your operating model divides your half again, between security and the teams that build.
Three patterns cover most organizations.
| Model | Who Decides | Who Executes | Best Fit | Failure Mode |
|---|---|---|---|---|
| Centralized | Security team holds every decision | Security team | Small organizations, few engineering teams, heavily regulated workloads | Security becomes the queue everyone waits in, so teams route around it |
| Federated | Security sets rules and thresholds; teams decide within them | Platform and product teams | Multiple teams shipping independently on shared infrastructure | Standards drift apart, with no feedback loop from the teams back to the rules |
| Embedded | A security champion in the squad decides within stated limits | The squad itself | Many autonomous squads on a mature internal platform | Champions get the title but no time, no authority, and no escalation path |
Choose by counting decisions rather than headcount. If the security team is the accountable owner for more decisions than it can make in a week, the model is already federated in practice, and only the documentation disagrees. In multi-cloud environments, federation is usually forced on you, because provider-specific decisions land with whoever knows that provider.
Embedded models are where integrating security into DevOps becomes an ownership question. A champion who can approve a low-risk exception locally needs a written limit and a stated escalation path, or the role degrades into a mailing list. Sourcing part of the delivery layer to a managed cloud security provider or an MSSP is a staffing decision inside the model, because the decision rights stay with you either way.
Measuring Security Program Success
Measure the model on whether decisions get made and controls stay owned. Alerts triaged, scans completed, and policies published all rise when the program is healthy and when it is quietly failing, so they settle nothing.
Decision latency. Time from a decision being requested to being made, tracked for exceptions and risk acceptances. Rising latency is the earliest signal that a model has centralized past its capacity.
Control ownership coverage. The share of controls with a named, current owner, reconciled against the directory quarterly. Every departure is a chance for this number to drop without anyone noticing.
Exception aging. How many exceptions are past their expiry date, and how old the oldest one is. This is the most honest number in the set, because nobody games it upward.
Mean time to remediate. Broken out by owning team, not aggregated. The aggregate hides the team that has been accountable on paper for six months with no capacity to act.
Escaped-risk rate. How often a risk reaches production despite a control designed to stop it. Each instance points at a specific gap: a missing owner, a rule nobody could apply, or a handoff with no receiver.
Five is enough. If a metric has never changed a decision, stop collecting it.
Security Operating Model Best Practices
Start from the decisions that stalled, not the org chart. List every security decision that took more than a day in the last quarter and ask who should have made it. That list is the first draft of your model, and it is usually shorter than fifteen items.
Pilot on one team before you publish. A model written in a document and rolled out to twelve teams fails in twelve places at once. Run it with one platform team for a month, then fix what broke.
Make ownership visible where the work happens. An ownership spreadsheet decays because nothing forces it to change when the team does. Put owners in the resource tags, the CODEOWNERS file, and the ticket template, so the record updates as a side effect of the work.
Kill a rule whenever you add one. Models accumulate. Every new approval step is a new place for work to stop, and the ones added after an old incident are rarely revisited.
Let the model change without a reorg. Decision rights should be editable by the security leader who owns them. If changing who approves an exception requires a reorganization, the model will stay wrong until the next one.
How Orca Supports a Cloud Security Operating Model
No product supplies an operating model. Governance, decision rights, and processes are yours to define. What a platform determines is whether the model you designed can actually run.
Federated and embedded models depend on every team working from the same prioritized view of risk. Orca provides that shared context by collecting runtime, configuration, and identity data agentlessly through SideScanning™.
Agentless coverage helps eliminate blind spots caused by workloads that were never instrumented, while findings are correlated and prioritized by exploitability and blast radius rather than severity alone. That gives platform, application, and security teams the same prioritized view of the assets they own. Get a demo to see how it works across your environment.
Frequently Asked Questions about Security Operating Models
Strategy decides what to pursue. The operating model decides who runs it and how. A strategy names the risks worth spending on over the next few years. The model names who approves an exception on a Tuesday, which team patches the shared image, and when an incident escalates. A strategy without a model is a document. A model without a strategy still functions, though it optimizes for whatever the last incident taught it.
The CISO or the most senior security leader owns the model, meaning they own the decision rights map and the authority to change it. That is different from owning the controls inside it, most of which belong to platform, engineering, and product teams. The distinction matters during incidents: the model’s owner decides how the organization decides, and the control’s owner decides what to do.
Even more than a large team, though it needs a much shorter one. A three-person team has no bench to absorb ambiguity, so a single departure removes an entire decision path. The useful version for a small team is one page: five to ten decisions, one accountable name each, and a fallback. Skip the RACI matrix and the committee structure until there are enough teams that ownership can genuinely be unclear.
A security operating model should document decisions, not every task. Focus on the points where ownership changes hands, approvals are required, or ambiguity creates delays. Most organizations need a clear map of decision rights, escalation paths, and accountable owners, while the detailed procedures belong in runbooks maintained by the teams that execute them.
Review it on triggers rather than a calendar, with an annual floor as a backstop. The triggers that actually invalidate a model are structural: a reorganization, an acquisition, a new cloud provider or region, a shift in regulatory scope, and any incident where the delay came from deciding rather than fixing. That last trigger is the most useful and the most ignored. When a postmortem timeline shows more time spent finding the decision-maker than remediating, the model is what failed, and the responders worked around it.
Table of contents
- Key Takeaways
- What Is a Security Operating Model?
- Why Every Organization Needs a Security Operating Framework
- Core Components of a Modern Security Operating Model
- Aligning Security Strategy with Business Goals
- Cloud Security Operating Models
- Measuring Security Program Success
- Security Operating Model Best Practices
- How Orca Supports a Cloud Security Operating Model
- Frequently Asked Questions about Security Operating Models