We already know SAMM's grid: 5 functions, 15 practices and 2 streams per practice. Now it is time to measure. The maturity assessment is the heart of SAMM: it turns a hunch ("I think we're weak on security testing") into a comparable figure ("Security Testing is at maturity 1"). In this lesson we explain what levels 0 to 3 mean, how a practical self-assessment is done practice by practice through questions, how a scorecard is built and how to interpret it. And we apply it: we will do BazarNube's real self-assessment with its complete scorecard, which will be the baseline for the next lesson's roadmap.

1. The maturity levels: from 0 to 3
2. How it is scored: streams, questions and answers
3. The step-by-step self-assessment process
4. Anatomy of a scorecard
5. BazarNube's self-assessment: complete scorecard
6. Interpreting the results

Each SAMM practice sits on a common scale of four rungs. The idea is the same for all 15 practices: it describes how much and how well something is done, not whether it is "good" or "bad".

Keys to not going wrong when scoring:

• The levels are cumulative: to be at 2 you must meet what 1 requires; to be at 3, what 2 requires.
• The scale measures coverage and consistency, not effort. Doing something heroic once is still level 1.
• SAMM allows fractional scores (e.g. 1.5) when a practice is met partially or only in some teams. It is normal and useful.
• The goal is not to reach 3 in everything. The desirable level depends on the business risk (we will see this in 05-04).

SAMM provides a toolbox (an official spreadsheet) with assessment questions for each practice. Each practice has two streams, and each stream is explored with questions whose answer is graded. The result of the answers determines the practice's level.

The answers usually follow a scale like:

• No (not done) → contributes 0.
• Yes, partially / for some teams → contributes an intermediate value.
• Yes, for most → contributes more.
• Yes, fully and consistently → contributes the maximum.

Example of questions for the Education & Guidance practice (Governance):

With mostly "No" or "sometimes" answers, this practice sits at maturity 0-1. The logic is the same for all 15 practices: you answer the questions of its two streams and derive the level.

A well-run SAMM self-assessment follows these steps:

1. Define the scope: which part of the organization is assessed (at BazarNube, the whole product unit).
2. Choose a facilitator: someone who runs it and keeps neutrality (the AppSec role).
3. Collect evidence: do not score from memory; look for proof (pipelines, policies, tickets, minutes).
4. Interview the owners: each function has its owner (05-02); ask them about their practices.
5. Answer the questions of each stream honestly.
6. Assign the level of each practice (0-3, allowing fractions).
7. Consolidate everything into a scorecard.

Golden rule: assess with evidence, not with optimism. If nobody can show the policy, the policy does not exist for maturity purposes.

The scorecard is the assessment's deliverable: a table with the 15 practices, their current level and (later) their target. It usually adds an evidence column and a comment column. Its value is twofold: it gives an executive snapshot and serves as a baseline for measuring progress in the next assessment.

A minimal scorecard has these columns:

• Function and Practice: the row being assessed.
• Current level (0-3): the result of the self-assessment.
• Evidence: what the score is based on.
• Target and Gap: filled in when planning (05-04).

We apply everything above. After interviewing Lucía (Design/Implementation), the SRE (Operations), the CTO (Governance) and with AppSec facilitating Verification, this is BazarNube's baseline scorecard (current level, 0-3 scale):

Average score per function (simple average of its three practices):

The numbers are only worth something if they are read well. From BazarNube's scorecard we extract:

• Governance is the weakest point (0.7), dragged down by Education & Guidance at 0. It makes sense: BazarNube has invested in verifying the product (module 4) but not in governance or culture. It is a typical gap of teams that start with the technical side.
• Design stands out (1.3) thanks to Security Requirements at 2, a direct inheritance from the ASVS work. You will notice that the two most mature practices (Security Requirements and Requirements-driven Testing, both at 2) are precisely the ones module 4 touched. Consistency of the thread: verifying the app raised those two practices, but left the rest flat; exactly what we anticipated in 05-01.
• Verification is uneven: strong in requirements-driven testing (2) but with Architecture Assessment at 0. What was asked for is tested, but the design is not reviewed.
• Operations is homogeneous at 1: things get done, but informally and reactively, with the legacy as a drag.

Useful cross-cutting readings:

• An isolated 2 does not save a function: Design has one practice at 2 and two at 1; the average misleads if you do not look at the detail.
• Zeros are attention priorities, not necessarily the first things to fix: they must be cross-referenced with risk (05-04).
• Compare against yourself, not against an ideal: the value of this scorecard will appear when reassessing in six months and seeing the trend.

Important: a scorecard is not a pass/fail grade. It is an honest starting point. And BazarNube now has one.

• Scoring from memory or with optimism. Without evidence, the practice does not count. An inflated scorecard is worse than a low but real one.
• Confusing "we did it once" with level 2. A heroic, one-off act is level 1; the 2 demands consistency and documentation.
• Forgetting that levels are cumulative. You cannot claim 3 if you do not meet 1 and 2.
• Looking only at the average per function. It hides practices at 0. You have to read practice by practice.
• Treating the grade as a judgment. SAMM measures to improve; the number exists to be compared with itself over time.
• Tip: use SAMM's official toolbox (the spreadsheet with the questions). It saves arguments and makes the assessment repeatable across semesters.

Exercise 1. Classify each situation into its maturity level (0, 1, 2 or 3): (a) "Each team reviews dependencies however it likes, some don't do it". (b) "There is no incident management process at all". (c) "There is a documented, tested incident response procedure with metrics reviewed each quarter". (d) "All teams follow the same documented code review standard".

Exercise 2. In BazarNube's scorecard, Education & Guidance is at 0 and Security Requirements at 2. Explain why that difference is consistent with what BazarNube has done in the previous modules.

Exercise 3. Choose a BazarNube practice that is at level 1 and write one assessment question whose answer would help decide whether it could rise to 2. Indicate which answer would correspond to a 2.

Solution 1. (a) Level 1: it is done inconsistently and depends on each team. (b) Level 0: the practice does not exist. (c) Level 3: documented, tested and measured with periodic review. (d) Level 2: consistent and documented across the organization, but without the measurement/optimization part that characterizes a 3.

Solution 2. BazarNube dedicated module 4 to verifying the product with ASVS, turning security requirements into acceptance criteria: that matured Security Requirements to 2. But it never invested in governance or culture: there is no training plan or champions, so Education & Guidance remains at 0. It is the expected gap of a team that starts with the technical side and has not yet matured the organization, exactly the motivation for adopting SAMM.

Solution 3. Example with Secure Build (level 1): question — "Is a dependency analysis (SCA) run automatically and mandatorily in the pipeline of all services, both npm and Maven?". A 2 would correspond to "Yes, in all services consistently and documented"; a "only in some" or "manual" would still be 1.

We now know how to measure: the levels 0 to 3 describe coverage and consistency, the self-assessment is done with per-stream questions and evidence, and the scorecard consolidates the picture. BazarNube's baseline reveals a clear pattern: strong where the ASVS touched (requirements and requirements-driven testing at 2), weak in governance and culture (Education & Guidance at 0), and homogeneously initial in operations. But a snapshot does not improve anything on its own. In the final lesson of the module we will take the step that gives meaning to it all: setting a maturity goal, building an iteration-based roadmap that takes BazarNube from this baseline to its goal, prioritizing improvements by risk and establishing the reassessment cycle that turns SAMM into continuous improvement.