Tessara
Security Operating Model
Select a pillar to explore
The Problem
Every security organization faces the same fundamental challenge: how do you decide what to work on, in what order, and how do you explain those decisions to the people funding the program?
Without a consistent model, security teams end up reactive — chasing the latest headline, scrambling to meet audit deadlines, or building capabilities that sound impressive but do not address the risks that actually matter to the business. Worse, when leadership asks “are we secure?” or “why do we need this budget?”, there is no structured answer. Just a collection of projects and a hope that the narrative holds together.
The Security Operating Model exists to solve that. It provides a repeatable structure for how a security organization sets direction, prioritizes work, and justifies its decisions — to technical teams, to executives, and to the board.
Four Pillars
The model is built on four pillars. Each addresses a distinct category of input that shapes security strategy. There is overlap between them — this is intentional. The separation exists to make each pillar independently actionable while preserving the relationships that connect them.
Minimum Viable Security. If your organization does nothing else, get these fundamentals right. MVS is the set of non-negotiable security basics that any business must implement to maintain a defensible posture. MFA, endpoint protection, patching, logging, and access control are not optional. They are the floor.
Evidence-Based Framework. Pick a framework that fits your business and market — NIST CSF, CIS Controls, ISO 27001, or similar. The framework builds on your MVS foundation, providing a structured growth roadmap that can be measured over time.
Enterprise Risk Management. The governing function of the model. ERM justifies the amplitude and magnitude of security investment and acts as the prioritization engine for work across all four pillars.
External Governance. Everything your organization is required to do based on forces outside your control: industry expectations, legislative and regulatory mandates, legal obligations, insurance requirements, and financial audit obligations where security controls are in scope (SOC 1 audits — relevant here only to the extent that IT general controls underpin financial reporting).
How the Pillars Relate
The four pillars are not independent silos. They interact:
MVS is a subset of the framework. Everything in MVS maps to controls within your chosen evidence-based framework. MVS is the prioritized starting point; the framework is the full roadmap.
Risk informs framework selection. Your organization’s risk profile should influence which framework you adopt and where you invest most heavily within it.
External governance augments MVS. Regulatory and contractual requirements may add controls beyond what MVS covers, expanding the baseline your organization must meet.
External governance informs risk. Compliance failures, regulatory penalties, and contractual breach exposure are risk scenarios in their own right.
Risk governs investment across all pillars. Enterprise Risk Management is the arbitration layer. When there are competing priorities, risk provides the decision-making structure.
Who This Is For
The Security Operating Model is not prescriptive about tools, team size, or budget. It is a thinking model — applicable to any organization that needs to answer the question: “how should we be spending our security resources?”
If you are a CISO building a program from scratch, this gives you the scaffolding. If you are an IT leader inheriting an existing security function, this gives you a diagnostic. If you are an executive trying to evaluate whether your security investment is well-directed, this gives you the framework for that conversation.
The Security Operating Model is a core part of how Tessara approaches security program development. Contact us to discuss how it applies to your organization.