In Your First 90 Days as an AppSec Leader, Measure Before You Move
When you take over application security, there is immediate pressure to demonstrate action. New tooling, pipeline integration, organizational realignment — these are visible and tangible. They feel like progress.
But speed without orientation creates technical debt in security programs just as surely as it does in software.
In my experience, the most disciplined first move in a new application security leadership role is not to buy something. It is to measure something. Specifically, to conduct a structured maturity assessment using the Building Security In Maturity Model (BSIMM).
What BSIMM Actually Is
BSIMM — the Building Security In Maturity Model — is not a certification and it is not a prescriptive checklist. It is an observational study of real-world software security initiatives. The framework is derived from studying more than a hundred organizations and documenting what mature programs actually do in practice.
The model organizes 128 observable activities across four domains:
Governance
Intelligence
SSDL Touchpoints
Deployment
Each domain contains practices, and each practice contains specific activities that can be observed, validated, and measured.
This matters because BSIMM provides something rare in security: an industry baseline grounded in operational reality. It gives you a vocabulary and structure for discussing software risk in a way that engineering, governance, and executive leadership can all understand.
Why a Maturity Assessment Should Come First
In fintech especially, application security is not just an engineering discipline. It is a risk management function tied directly to revenue, regulatory scrutiny, and operational resilience.
When your systems process payments, manage financial data, or support factoring operations, software risk is business risk. That risk shows up in:
PCI obligations
FFIEC and supervisory expectations
Customer due diligence questionnaires
Software supply chain scrutiny
Board-level resilience discussions
Before you add tools or expand staff, you need to understand where your control surface actually stands.
A structured BSIMM assessment does five critical things:
Establishes a defensible baseline
Surfaces control inconsistencies across portfolios
Highlights gaps relative to peer organizations
Translates technical controls into business risk language
Creates the foundation for a sequenced roadmap
Without this baseline, every investment discussion is subjective.
A Practical Process for Conducting a BSIMM-Based Assessment
BSIMM is not a step-by-step compliance guide, but it clearly describes how assessments are performed and how scorecards are created. The process is structured, interview-driven, and evidence-based.
Here is how I approach it.
1. Start With the Model, Not the Spreadsheet
Before sending questionnaires, review the four domains and associated practices. Understand how governance connects to engineering execution and how deployment feeds back into defect management.
This prevents shallow scoring and helps you see patterns rather than isolated controls.
2. Interview Across Functions
No single stakeholder sees the entire software risk picture. BSIMM emphasizes interviewing broadly.
In a fintech environment, that means engaging:
Application security
Engineering leadership
DevOps and cloud infrastructure
QA and testing
Incident response
Privacy and compliance
Vendor management
Each group owns a piece of the control ecosystem. The assessment must reflect that reality.
3. Validate Depth and Coverage
An activity should not be marked as mature simply because it exists in policy. BSIMM makes clear that credit should only be awarded when there is sufficient breadth and depth.
For each activity, determine:
Is it consistently applied across business units?
What percentage of applications are covered?
Is it embedded in CI/CD pipelines?
Is there telemetry?
Can evidence be produced?
In regulated industries, artifact availability is as important as control existence.
4. Score With Nuance
Binary scoring obscures maturity. A graduated scale communicates progression:
0 – Not present
1 – Ad hoc or inconsistent
2 – Documented and repeatable
3 – Automated, measured, and scaled
In fintech, I also recommend adding columns for:
Regulatory relevance
Revenue impact
Customer trust exposure
Supply chain dependency
This shifts the conversation from “Are we doing code review?” to “What is the residual business risk if this control fails?”
5. Compare and Prioritize
Once scored, compare results against both internal expectations and industry prevalence. Identify:
Foundational gaps that most peer firms have already addressed
Controls that exist but lack scale
Emerging areas such as SBOM generation or toolchain integrity that are becoming industry norms
Then sequence improvement in a way that aligns with business velocity and regulatory scrutiny.
The Fintech-Specific Imperative
In financial services and fintech, maturity conversations cannot stop at development lifecycle touchpoints. They must extend into:
Software supply chain risk management
Development toolchain integrity
Third-party and open source visibility
Incident response integration with engineering
Documentation capable of surviving supervisory review
Regulators increasingly expect demonstrable software assurance. Customers increasingly ask for evidence of secure development practices. Supply chain attacks increasingly target build systems rather than runtime environments.
A maturity assessment rooted in BSIMM gives you a structured way to answer those questions confidently.
What Leadership Actually Cares About
Executives do not need 128 activity scores. They need clarity on three things:
Where are we strong?
Where are we exposed?
What is the prioritized plan?
The final output of a BSIMM assessment should therefore include:
A visual heatmap across Governance, Intelligence, SSDL, and Deployment
A short list of high-impact gaps tied to business risk
A 6–12 month roadmap aligned to growth and regulatory realities
When presented correctly, the maturity assessment becomes a strategic artifact, not an operational spreadsheet.
Download the Scorecard
To make this actionable, I have recreated a structured BSIMM-based scorecard designed for initial maturity assessments, with an emphasis on both engineering controls and business risk alignment.
You can download the template here:
Download the BSIMM Maturity Scorecard Template → Scorecard
It includes:
Activity-level scoring aligned to the four BSIMM domains
A graduated maturity model
Space for evidence, coverage, and ownership
Fields to connect controls to regulatory and business impact
A summary view suitable for executive reporting
Use it as a starting point. Adapt it to your environment. The goal is clarity, not perfection.
Measure Before You Move
In a new role, credibility is built through disciplined judgment. A structured maturity assessment demonstrates that you understand software security not as a collection of tools, but as a coordinated risk management function.
Before buying. Before reorganizing. Before declaring transformation.
Measure.
Then move with precision.