This document outlines the steps required to prepare for and establish a security partners program.
This list is for the security partner program manager to perform.
- Determine security partner program owner: Designate an individual to serve as the technical program manager responsible for ensuring smooth operations, identifying partners, addressing engineering needs, managing reporting and metrics, handling escalations, and prioritizing the highest risk applications and teams.
- Identify initial riskiest applications: When first establishing a security partner program, start with a product or feature that would have a high impact if exploited or has historically faced security challenges. Ideally, choose a team that already has a strong relationship or alignment with the security team. This enables collaboration with teams that are more open to piloting the program and offering constructive feedback.
- Meet with engineering/operations/product leaders: Identify pain points, products or features handling financial transactions or PII, applications tied to large customer contracts, teams with a significant history of bug bounty or scanner findings, and teams struggling to remediate vulnerabilities within SLA.
- Identify pilot team: Choose the highest risk application or product that has historically struggled with remediating issues, identifying fixes, or addressing scanner findings. Engineering teams working on these products are likely to welcome additional support and may be more willing to collaborate and advocate for the value of the partnership.
- Identify security engineer to support pilot: Once the pilot team or application has been identified, you will need to allocate time for a security engineer who can autonomously collaborate with engineering to enhance the security of their products. This role will likely require a more senior AppSec team member (e.g. L5) who excels not only in technical expertise but also in collaboration. The security partner's primary responsibilities include:
- Understanding team priorities and active work - The security partner should be aware of the team’s current and upcoming work. Specific approaches for gathering this context are outlined below, beginning with "Bootstrap the partnership".
- Security design reviews and threat models - The security partner will review all Product Requirements Documents (PRDs) and Technical Design Documents (TDDs or tech specs) to identify architectural security concerns or potentially risky functionality. They will conduct deep dives into security controls that need to be implemented (e.g. appropriate encryption based on data type, reuse of existing approved authentication solutions, etc.), verify that the design is as secure as possible, flag penetration testing needs, and, if necessary, take the lead in co-designing safer approaches with engineers to meet product and feature goals.
- Scanner assistance - Ensuring that the appropriate security scanners (SCA, SAST, DAST, Cloud, etc.) are running.
- Remediation guidance - Providing support and recommendations for fixing identified security issues.
- Identify if a pentest is needed - The security partner will assess whether risky functionality should be tested for vulnerabilities before going live. If trained, they can conduct penetration testing themselves or engage the relevant security team responsible for product or infrastructure focused penetration testing. This may require External Penetration testing by a third party.
- Flagging plans to other stakeholders - The security partner has a limited but focused view of the team's plans. They may identify functionality that has compliance, privacy, or other operational security implications beyond the scope of the application security team. The partner collaborate with the appropriate engineering/product members to ensure they engage with the relevant stakeholders early (e.g. privacy, compliance). While it is ultimately the responsibility of the engineering or product team to engage these groups, poor processes, expedited releases, or a lack of clear procedures may prevent this from happening. The engineering team will appreciate being directed to the right contacts, as it ultimately helps them ship products faster.
- Bootstrap the partnership: Ensuring that the security partner is closely engaged with the engineering team accelerates ramp-up and sets the foundation for a successful partnership. The following approaches should be explored:
- Identify team meetings - The security engineer should be aware of and invited to the engineering team’s standups, status meetings, and planning meetings (e.g. biweekly, monthly, quarterly, yearly). This provides insight into the team’s current focus, future plans, and potential pain points where the security partner can assist.
- Identify slack channels for these teams and become a fly on the wall - The security partner should join all relevant Slack channels, including those focused on product and product management, engineering, and operations (e.g. monitoring).
- Identify Jira projects and Dashboards - Staying informed about the engineering team’s priorities includes being aware of their Jira projects, sprint work, kanbans, and dashboards. This helps the security partner identify ongoing or upcoming risky functionality that may require a design or code review.
- Kickoff meeting with eng leadership for pilot team: It is important to set clear expectations with both the engineering team and the security partner on how the pilot will function. The primary goal of the security partner is to provide a white-glove service to a specific product or team, assisting with:
- Security testing needs
- Remediation guidance
- Scanner support
- Security design reviews and threat modeling
- Routing concerns to other security teams when necessary
- Helping engineering teams find the right point of contact
- Security incidents tied to the products they support
- Pilot the program - At this stage, you have buy-in from the security team, the security partner, and the engineering and/or product teams, with a dedicated team for the pilot. The security partner is expected to carry out the tasks outlined earlier.
- Identify metrics: Define metrics to measure the success of both individual security partners and the overall program. See 'Security Partner Metrics' for ideas.
- Identify coverage methodology for expansion: Starting with the riskiest applications is a logical approach. However, as the program demonstrates value and scales, it is essential to determine how security partners will align with the business. Below are common alignment strategies:
- Product alignment - Assigning security partners to specific external facing and internal products.
- Team or organizational alignment - Dedicating a security partner to support a specific engineering, product team, or an entire organization. This allows them to focus exclusively on the security needs of that group.
- Product type alignment - Aligning security partners based on technology areas such as frontend, backend, mobile, etc., when appropriate.
Note: The approach may change as the company grows, or organizations redefine themselves/reorganize.
- Perform a retrospective: After the partnership has been running for some time (e.g. 1–3 months), schedule a retrospective with relevant members from engineering, operations, product, and security teams (including the security partner). Gather feedback on what went well, what was just "okay," and what could be improved. Identify whether adjustments or pivots are necessary. This feedback is critical for tailoring support to individual teams, understanding priorities, and identifying additional support needs for other teams. It's important to note the needs of teams may vary so be prepared for slight variances between teams.
- Expand the partnership program: Identify another product or team to onboard. If the current security partner has capacity, they can take on the new team; otherwise, allocate a new team member. Some teams may be small and require minimal effort once the partnership is established, while larger teams or complex products may demand multiple security partners to manage the workload effectively.
This list provides the designated security partner with actionable preparation steps to establish a meaningful security partnership.
- Get added to relevant meetings: Sync with your engineering manager to determine which meetings you should attend. Over time, the number of meetings you attend should decrease as the most relevant ones become clear. Since meeting structures may vary across teams and organizations, avoid making assumptions; these meetings are a primary way to stay informed about priorities and ongoing development.
- Review quarterly plan: Review the team's goals and OKRs to understand their priorities. This helps you anticipate the right timing for security reviews and informs other security stakeholders about key timelines.
- Review release/sprint priorities: Stay updated on the team’s immediate and upcoming development priorities to proactively identify security needs. This involves gaining access to all relevant Jira projects, dashboards, sprints, and Kanban boards.
- Get access to repositories: Ensure you have full access to all relevant code and configuration repositories. Additionally, obtain access to security scanning results to identify pain points in scanning and remediation gaps.
- Request Product Requirements Documents (PRDS) and Technical Design Documents (TDDs): Understand both the design and implementation details for each project to provide effective security guidance. Evaluating both is critical, as there are often deviations from the initial design in the final product.
- Identify ticketing flow: When conducting design reviews, threat modeling, code reviews, or other significant support, determine how to track these requests in your bug tracker (e.g. Jira). This enables you to document your work, generate metrics, and communicate your priorities effectively.
This list provides engineering leadership with actionable preparation steps to establish an impactful security partnership.
- Determine what meetings to invite the security partner: The security engineer should be aware of and invited to engineering team standups, status meetings, and planning meetings (e.g. biweekly, monthly, quarterly, yearly). This keeps the partner informed about current focus areas, future plans, and pain points they may be able to assist with.
- Invite the partner into applicable slack channels: The partner should be included in all relevant Slack channels, including those focused on product management, engineering, and operations (e.g. monitoring).
- Share codebases: The security partner should have full access to all relevant repositories for code and configurations, as well as access to security scanning results for your products.
- Share relevant documentation: Ensure the partner has access to both PRDs and TDDs and can stay informed about new initiatives underway.
- Share Jira projects and dashboards: To keep the security partner informed about your team's focus areas, ensure they have visibility into current plans (e.g. sprint work) and dashboards. This helps identify any existing or upcoming risky functionality that may require a design review or code review.
- Establish regular syncs with the security partner: Check in biweekly or at least once a month with the security partner to stay informed about risks within your group. This will help you assess whether the partnership is successful, requires adjustments, or if critical issues or concerns need resolution.
Checklist version 1.0 copied from Sectemplates.com 2025