This document outlines initial metrics for measuring the effectiveness and operations of your security partner program. It also includes experimental metrics that may be useful or provide ideas for your program.
This metric highlights the coverage of products by security engineers/partners. It can be measured in several ways:
- Total coverage across all products or features
- Total coverage across teams
- Total coverage across product types (e.g. frontend, backend, mobile, etc..)
- Total coverage across high/critical risk products/teams
This can potentially highlight:
- Engineering teams without proper security resourcing or prioritization
- Risk coverage across high/critical risk products/teams
Notes:
- This metric can be useful when developing resource requests for yearly planning, helping to demonstrate hiring needs to improve coverage.
- It can also help determine if a single organization or product is too large for one partner to manage effectively.
This metric can highlight pull requests supported, mitigation guidance provided, design reviews or threat models conducted, and general support activities. It can also help identify:
- Products or teams requiring additional support
- Low-volume engineering teams, allowing security to reprioritize efforts
- How each security partner is supporting engineering and product teams, uncovering opportunities to enhance guidelines, automate testing, improve mitigations, and more.
This metric can highlight how a security partner's time is being spent, providing insights into:
- The percentage of time allocated to different support types (e.g., PR reviews, security design reviews, remediation guidance, and miscellaneous support).
- Volume trends over time, which may indicate release activity.
- The rate of PRD versus TDD reviews, offering insights into the percentage of projects that are canceled before going live or skip the TDD review entirely.
This section contains metrics that are strictly experimental. They are included here for you to use as-is, modify to fit your needs, or serve as inspiration for other ideas. Too often, security professionals fail to experiment with measuring the impact of their work. Hopefully, this section encourages and inspires you to push boundaries.
Measures the actual time spent by the partner developing and implementing the fix versus the time required to fix similar issues without a partner. This allows you to quantify the direct cost of the partner against the estimated engineering effort in hours. It provides a quantifiable cost comparison based on the partner's hourly rate versus the engineering cost per person.
Measures security incident resolution time when a security partner is involved versus when one is not. The hypothesis here is to demonstrate, over time, a slight reduction in resolution time due to identifying the right stakeholders more efficiently, improving risk exposure context, enhancing communication, and better understanding the environment in which a vulnerability exists.
Metrics version 1.0 copied from Sectemplates.com 2025