Role: The Owner
For AppSec leaders: here's what you own, and what you should delegate to stay sane.
Taking ownership of your company’s application security can be a fulfilling mission, but it can burn you out quickly if you’re not careful. This deep dive on the Owner role sets clear boundaries around what you can take on and what you must strictly delegate.
Who is the Owner?
The Owner is one of six roles within the AppSec Ownership Model and refers to:
The person who takes ownership of AppSec and mainly drives the initiative.
This includes:
AppSec lead (operational owner)
AppSec teams (shared responsibility)
CISO / C-suite (strategic fallback if no dedicated owner exists)
One could argue that ownership ultimately lives within the executive leadership, but for the sake of this model, we refer to the person who mainly drives and represents AppSec within the company.
What AppSec domains does the Owner own?
As the Owner, you mainly focus on four AppSec domains:
Security Strategy | Define the overall strategy with long-term goals and KPIs to measure progress.
The strategy needs to be aligned with business goals and approved by the executive leadership (Backbone). Close collaboration between both roles is absolutely necessary.
Security Tooling | Select and configure security tools in alignment with the overall strategy.
This includes anything from scanners to vulnerability management platforms or runtime protection. The requirements for each tool should be derived from the base in collaboration with the development teams.
Incident Readiness | Define and train processes for incident response and zero-day vulnerabilities.
As the Owner you should provide process definitions, templates and checklists, as well as detection mechanisms. Everything that saves time and reduces error under pressure. Of course these structures need to be built and derived from the operational reality.
Security Culture | Detect cultural threats and actively shape cultural change.
A strong security culture will make every other effort you take more efficient and sustainable. Nobody can change culture alone, but someone must attempt to shape it with intention and a plan, one step at a time.
What AppSec domains does the Owner support?
As the Owner, you’re involved in all domains. These are the remaining domains, you only support:
Secure Design & Secure Coding | Define standards and provide best practices for secure design and coding.
Vulnerability Management | Define the process and prioritization rules based on risk.
All these domains must be mainly driven by the development teams, as you won’t have capacity or know all the details to own them. They are the main trap where AppSec leads burn themselves out when they take on too much in those areas. Make sure you strictly separate between operational details and defining structure.
Now that you see the bigger picture, let’s make accountability explicit.
What is the Owner accountable for?
Here’s what you can hold yourself accountable for:
Designing and evolving the AppSec strategy, including roles, responsibilities, policies, and processes.
Making structural decisions on security tooling, training programs, and cross-team standards.
Prioritizing global security efforts based on input from teams, risk exposure, and business impact.
Defining how threat modeling, vulnerability management, and risk acceptance are handled across teams.
Defining roles and responsibilities within the incident response process and ensuring readiness across involved teams.
Enabling security champions through clear guidance, training resources, and structured feedback.
Ensuring continuity of strategic AppSec leadership, including defined delegation in case of absence.
Supporting awareness and compliance activities in alignment with strategic goals.
Defining relevant KPIs for application security and regularly reporting them to the executive leadership.
Actively aligning AppSec goals with business priorities, customer value, and delivery strategy through regular collaboration with the management.
Temporarily owning unstructured security gaps to prevent risk blind spots with the explicit goal of transitioning them into stable ownership based on field experience.
I know the list is long. If possible, these accountability should be shared by an AppSec team. If you’re alone, make sure you are extra strict in what to prioritize and what to reject at least for the moment. Nobody wins when you ignore your limits and eventually need to give up.
What is the Owner NOT accountable for?
There are certain operational things you need to delegate because you just can’t handle them.
Here’s what you are explicitly NOT accountable for:
Fixing vulnerabilities, reviewing code, or directly supporting delivery teams operationally.
Leading operational incident response unless specifically defined as part of the process.
Making final decisions on budget, procurement, or staffing (that belong to executive leadership).
Taking over prioritization decisions that belong to product or project management.
Owning team-level backlogs or covering missing security champions in delivery teams.
Acting as a full-time trainer or one-on-one coach for teams.
There are other roles accountable for those tasks. If you notice they don’t own their part, help them understand why they must and ask the Backbone to support you up if necessary.
Who does the Owner escalate to?
If you find yourself confronted with tasks, that should not be on your desk, you have two options for escalation:
Gatekeeper (e.g., project leaders) | When security goals are blocked by planning constraints or business pressure.
Use this path when KPIs are not met to figure out why they failed and how they can be supported, to get back on track. Don’t take over for them, just ask and lead them back on track.
Backbone (e.g., executive leadership) | For structural conflicts and priority trade-offs.
Use this path when you run into conflicts with the project leaders and their teams. When you can’t find solutions locally, call your Backbone for support. They ultimately decide if security is their first business priority in that specific case or if there are reasons to prioritize output. In that case, ask them to address the security requirements in their plan, with a clear near-term deadline.
Who does the Owner work with?
Apart from escalation, there are three roles that the Owner can work with:
Backbone (e.g., executive leadership) | For budget and strategy decisions related to AppSec capabilities.
The Owner should report at least quarterly directly to management to keep them informed. There should be a quick way to get their feedback or smaller decisions in between to reduce friction. This collaboration is the necessary foundation.
Advocate (e.g., security champions) | They lead the security champions program, which provides direct feedback from the base.
The Owner will usually lead the security champions program at least in the beginning. Later the security champions might be able to sustain the program themselves, but the Owner still needs to stay in touch with them. They are probably their best connection to the development teams to get honest feedback, needs and requirements to support development teams best.
Catalyst (external/optional) | Whenever they need access to deeper expertise, external validation or strategic sparring partner support.
The Catalyst can be any external coach or consultant that usually works exclusively with the Owner without taking ownership away from them.
The Owner is one of six roles within the AppSec Ownership Model, which defines clear accountability for everyone involved in developing secure software.