We have BazarNube's baseline: an honest scorecard that says where each practice stands. But a scorecard kept in a drawer improves nothing. SAMM's real value appears now, in the continuous-improvement cycle: setting where we want to go, plotting the path in realistic phases, prioritizing by risk, executing, measuring and reassessing. In this final lesson of the module we learn to define a maturity goal, build an iteration-based roadmap and close the cycle. We apply it with a complete BazarNube roadmap that goes from its baseline to an achievable goal. And with that we close the strategy, making way for the tools.

1. SAMM's continuous-improvement cycle
2. Defining the maturity goal (risk-based)
3. Calculating gaps and prioritizing
4. Building an iteration-based roadmap
5. BazarNube's roadmap: from baseline to goal
6. Measuring progress and reassessing
7. From the maturity program to the tools: bridge to module 6

SAMM is not a project with an end; it is a loop that repeats indefinitely. Each turn leaves the organization a little more mature and produces a new scorecard comparable with the previous one.

We already completed the first box (assess, in 05-03). This lesson walks through the rest of the loop. The usual cadence is to reassess every 6-12 months: enough for the improvements to take hold, without losing the pulse.

The first mistake to avoid is wanting to "take everything to 3". SAMM is risk-based: each practice's goal depends on how much risk it contributes to the business, not on an ideal. Setting the goal is a conversation between AppSec, CTO and Product.

Criteria for choosing each practice's goal:

• Business risk: BazarNube handles payments and personal data; the practices tied to that (data protection, secure deployment, incident management) call for a higher goal.
• External demands: enterprise clients and PCI-DSS push Governance and Verification.
• Cost/benefit: rising from 0 to 1 is usually cheap and very worthwhile; from 2 to 3, expensive and only justified where the risk demands it.
• Realism: a goal achievable in 12 months motivates; an unreachable one demoralizes.

For BazarNube, the committee sets a reasonable overall goal of "level 2 in the key practices", leaving some at 1 (enough for its current risk) and reserving the 3 for later. Not everything rises; what matters rises.

A practice's gap is simply goal − current level. Gaps order the work, but attacking the largest is not enough: they must be cross-referenced with risk and effort.

Simple prioritization matrix:

The 0→1 improvements are usually "quick wins": cheap, fast and with a big relative jump. It is a good idea to put them early to generate momentum and credibility with leadership.

A SAMM roadmap distributes the improvements across phases (iterations), each with concrete objectives, practices to move, an owner and a time horizon. Not everything is done at once: each phase is a small turn of the loop.

Best practices when planning the roadmap:

• Few practices per phase: 3-5 moves per iteration, not fifteen.
• Start with quick wins and high risk: it motivates and reduces the most dangerous first.
• One owner per improvement: reuse the function owners (05-02).
• Concrete actions: not "improve training", but "mandatory security onboarding + 2 champions".
• Remember that the "how" belongs to module 7: the roadmap says which practice to raise; executing the threat modeling, the DevSecOps pipeline or the awareness plan is module 7 content. SAMM plans; M7 does.

We start from the 05-03 scorecard. This is the 12-month roadmap in three phases. The "Current → Goal" column uses the baseline from the previous lesson.

Phase 1 (months 0-4) — Quick wins and culture

Phase 2 (months 4-8) — Governance and verification

Phase 3 (months 8-12) — Consolidate operations and data

Practices that are left at their current level this turn (goal = current), by risk/cost: Policy & Compliance (1), Security Architecture (1), Defect Management (1). They will be reviewed in the next cycle. And those already at 2 (Security Requirements, Requirements-driven Testing, inherited from module 4) are maintained, not allowed to degrade.

A compact representation of the roadmap in pseudo-YAML, useful for versioning alongside the repo:

A roadmap without measurement is a wish list. To close the loop:

• Define the success metric per improvement: not "we improved the build", but "100% of services run SCA in CI". Measurable and binary where possible.
• Review progress in each phase: at the end of each iteration, check which practices reached their goal.
• Reassess the complete scorecard every 6-12 months: repeat the 05-03 self-assessment and compare with the baseline. The comparison is the queen metric: it shows the trend and justifies the investment to leadership.
• Adjust the next cycle: raise goals where you got there, replan where you did not, incorporate new risks.

Example of how BazarNube's progress would look after Phase 1 (average per function):

Small steps, but measurable and in the right direction. That is exactly what SAMM seeks: not a heroic leap, but a sustained upward curve.

With this lesson we close module 5 and, with it, the strategy and governance part of the course. Let us take stock of the journey: BazarNube learned to verify its application (ASVS, M4) and to measure and mature its organization (SAMM, M5). It now knows what it wants to achieve and how mature its security program is.

Notice one detail of the roadmap: several improvements (Phase 2, Security Testing 1→2; Phase 1, Secure Build) talk about running security tests systematically. That is where the strategy touches the ground: to raise those practices you need concrete tools that find real vulnerabilities in the application. We have defined the what and the how much; now comes the with what.

That is the leap to module 6, OWASP ZAP. We move from strategy and organizational maturity to a concrete dynamic testing tool (DAST): ZAP, OWASP's interception proxy with which BazarNube will be able to scan its application for vulnerabilities and automate part of the verification that SAMM asks it to mature. From measuring the program, to testing the application with tools. We start with ZAP.

• Wanting to raise everything to 3. SAMM is risk-based: raise what the business needs and defer the rest. A realistic goal motivates; an impossible one paralyzes.
• Planning without prioritizing by risk. The largest gap is not always the first; it must be cross-referenced with the asset's risk and cost.
• A roadmap with no owners or metrics. Each improvement needs an owner and a measurable success criterion, or it is neither executed nor checked.
• Not reassessing. Without repeating the scorecard and comparing it with the baseline, SAMM loses all its value: it stays a snapshot, not a film.
• Putting too much in one phase. 3-5 moves per iteration; the excess guarantees that nothing gets finished.
• Tip: start each cycle with one or two quick wins (0→1). The early, visible momentum makes it easier to get leadership support for the more expensive work.

Exercise 1. For these three BazarNube practices, calculate the gap and order them from highest to lowest priority, justifying with risk and effort: (a) Education & Guidance, current 0, goal 1. (b) Security Architecture, current 1, goal 1. (c) Secure Deployment (secret management), current 1, goal 2, over a system that handles payments.

Exercise 2. Design a roadmap Phase 1 (3 improvements) for a different organization whose weakest point is Operations (everything at 0-1). Indicate the practice, current→goal, one concrete action and a plausible owner.

Exercise 3. The CTO asks: "How will I know in a year whether SAMM has been worth anything?". Answer in 3-4 sentences explaining what you would measure and how.

Solution 1. Gaps: (a) 1, (b) 0, (c) 1. Priority order: 1st (c) Secure Deployment — gap 1 but over payments (high risk), an exposed secret is critical; 2nd (a) Education & Guidance — gap 1, it is a cheap 0→1 quick win with big cultural impact; 3rd (b) Security Architecture — gap 0, it is already at its goal, no action needed this cycle. Priority is set by risk (c) above the size of the gap, which is equal in (a) and (c).

Solution 2. A valid example: (1) Incident Management 0→1: set up basic incident detection with alerts and an on-call channel — owner SRE. (2) Environment Management 1→2: define a patching policy with a schedule and owners — owner SRE. (3) Operational Management 0→1: inventory sensitive data and apply encrypted backups — owner SRE/DPO. (Any combination of 3 Operations practices with concrete actions and a plausible owner is correct.)

Solution 3. "I would repeat the SAMM self-assessment after a year and compare the new scorecard with today's baseline: if the roadmap's practices have risen in level, SAMM has been worth it. In addition I would check each improvement's concrete metrics (e.g. % of services with SCA in CI, existence of a tested incident plan). What matters is the measurable trend relative to ourselves, not an absolute grade."

We have closed the SAMM cycle: assess → goal → prioritize → roadmap → execute → measure → reassess. With a risk-based goal, a phased roadmap with owners and metrics, and a commitment to semi-annual reassessment, BazarNube turns its static scorecard into a continuous-improvement curve. With this, module 5 ends: the organization now knows how to verify its product (ASVS) and measure and mature its security program (SAMM). This closes the course's strategic block. In module 6 we come down from strategy to practice with OWASP ZAP, the dynamic testing tool with which BazarNube will start to find and automate the detection of real vulnerabilities in its application.