The goal of this program pack is to provide you with minimal information to establish a functioning, and impactful security partner program. This will enable you to adopt a security partnership model, and provide you with a repeatable process to scale up as needed.
We suggest reviewing the material in the order specified below.
A security partner program functions as a white-glove service provided by the security team, offering dedicated support to specific engineering teams. While traditional security operates as a consultancy supporting everyone, a security partner serves as a long-term, dedicated advisor to a specific organization or product line. This approach enables a security engineer to become a subject matter expert on a set of products and their technologies, foster closer collaboration with engineering, and improve communication and understanding of critical changes in product lines. The benefits of the security partnership model include:
- Context - The security partner is aware of past risks in a specific product, familiar with the codebase, core product functionality, and understands current security issues while also anticipating future risks.
- Execution speed - With historical context and familiarity with the product, security reviews such as design reviews and threat modeling can be conducted more efficiently, minimizing delays for the product and engineering teams.
- Advocacy - The security partner understands the challenges faced by the engineering team, including weak security controls in the technologies used, technological constraints, and architectural limitations inherited from shared components and services.
- Trade off identification - As risks are identified, solutions must be researched and proposed to address them. The partner has a comprehensive understanding of the products in their domain and can provide context-specific guidance, enabling quicker decision-making
This document defines stakeholders and their responsibilities.
This checklist provides a step-by-step guide to researching, piloting, testing, and rolling out security partners program at your company.
Below is an outline of a duties performed by a security partner. It aligns roughly with the context in the security partner checklist.
This runbook contains the steps outlined in the process diagram as a checklist with a strong focus on stakeholder support.
This document outlines starting metrics for a security partner program. I strongly encourage everyone to experiment with security focused metrics!
Question: What is a security partner?
Answer: A security partner is a dedicated security team member providing white glove security services to specific product and engineering teams. Think of a security partner, as an embedded appsec engineer that directly supports particular products or teams and provides white glove service. They assist with:
- Secure design review/Threat modeling
- Secure code reviews
- Penetration testing
- Security ambassador to the larger security and compliance organizations
- Security remediation specialist, available for teams to get assistance
- Security scanning support for the engineering team.
- Advocate for security initiatives that would benefit their supported teams.
Question: Why have a security partner vs standard appsec model?
Answer: Security reviews may rotate between members of the team and each time this occurs, each individual must ramp up onto the product line. Ultimately though, they will not have great historic context or context on the technologies and their limitations used by the team. A partner’s contextual knowledge of a product enables expedited reviews, potentially saving hours or even days compared to the traditional 'security review' rotation approach.
Question: How is a security partner different than a security champion?
Answer: A security champion, is generally a member of engineering/ops/it that has an interest in security or has been delegated by their leadership to support security related duties for the team. Whereas a security partner is a security engineer that supports specific engineering teams.
Question: Are there alternative names for security partners?
Answer: Some companies may also label them as embedded security engineers or dedicated security engineers. Yahoo, one of the first companies to adopt this model, called this role a 'dedicated paranoid'.
Question: Some of the activities under the security partner runbooks can be conducted without a security partner, can't they?
Answer: Yes, they can! While these activities can be used for general consulting-style infosec support, they should be performed regularly by a security partner.
Question: Was AI used to create this content?
Answer: No, AI was only used for spelling, grammar improvements, and image quality enhancements. All content was manually created by the authors/contributors.
Question: Why should I use this instead of chatgpt or other AI?
Answer: Material released on Sectemplates has been battle-tested in various companies ranging from 100 to 30,000 employees successfully and has been vetted by individuals developing and running these programs. AI can confuse standards, articles written by people who have never run such a program, and opinion pieces. Everything in Sectemplates has actually been utilized in the real world by qualified professionals.
Question: What software did you use to create the process diagram?
Answer: Lucidchart was used.
Question: I'd like to provide feedback, how should I do this?
Answer: You can either submit the feedback form on our site or cut a pull request.
Document version 1.0 copied from Sectemplates.com 2025