Sample report. Entirely fictional data: “Example Company” does not exist, and no figure on this page comes from a customer.
Application security engagement and progress report
Company-level aggregates — no personal data.
Scope
- Developers enrolled
- 38
- Declared headcount
- 41
- Coverage rate
- 93 %
Engagement
- Active participants
- 31
- Participation rate
- 82 %
- Assessments completed
- 412
- Median per active participant
- 11
Regularity
Regularity is what the texts literally ask for: training that is “ongoing” (DORA), “regular” (NIS2), “at least every twelve months” (PCI-DSS).
Progress
The first month in the period with data is set to 100. Absolute levels are not published.
Topic coverage
What the team worked on, mapped to the ten OWASP Top 10:2025 families.
- A01 — Broken Access Control
- A02 — Security Misconfiguration
- A03 — Software Supply Chain Failures
- A04 — Cryptographic Failures
- A05 — Injection
- A06 — Insecure Design
- A07 — Authentication Failures
- A08 — Software or Data Integrity Failures
- A09 — Security Logging and Alerting Failures
- A10 — Mishandling of Exceptional Conditions
This is coverage, not a pass rate: the block says which topics were worked on, never how well.
Regulatory mapping
This document is one piece of evidence among others. Each row also states what it does not establish.
| Framework | What it requires | What this report provides | What it does not provide |
|---|---|---|---|
| PCI-DSS 4.0 — req. 6.2.2 | Developers are trained at least every twelve months on software security relevant to their role, including secure design and coding. | A dated record of training activity over a rolling twelve months, by OWASP family, with the team’s participation rate. | The training itself, nor named proof that each developer was trained: the report is aggregated. |
| DORA (UE 2022/2554) — art. 13(6) | ICT security awareness programmes and digital operational resilience training, mandatory for staff. | Evidence that a programme exists and is followed over time, with its regularity measured. | The mandatory nature of the modules, nor coverage of all staff and management. |
| NIS2 (UE 2022/2555) — art. 21(2)(g) | Basic cyber hygiene practices and cybersecurity training. | Evidence of cybersecurity training for development teams, dated and verifiable. | Coverage of other populations, nor the nine other measures of Article 21. |
| ISO/IEC 27001:2022 — A.6.3 · art. 7.2 | A.6.3: awareness, education and training. Clause 7.2: competence, and retention of documented information as evidence. | Documented information, dated and verifiable, ready for the audit file. | The competence matrix, nor the effectiveness evaluation required by clause 7.2. |
These references place the report within your obligations. NakamaCyber certifies no compliance: the assessment is your auditor’s.
OWASP SAMM maturity
Governance › Education & Guidance › Stream A (Training and Awareness)
OWASP SAMM covers fifteen practices; this report documents only one. SAMM is a self-assessment model. NakamaCyber does not validate it.
What this document establishes — and what it does not
- The assessments are multiple-choice questionnaires taken online, unsupervised.
- Nothing prevents a participant from looking up an answer. The results therefore rest on participants’ good faith.
- What the document establishes is simple and verifiable: developers log in, take security assessments regularly, and their results improve over time. It is neither a proctored exam nor a certification.
- The document contains only company-level aggregates: no names, no email addresses, no individual results. Below 5 active participants, rates and the curve are not published.
- The figures are computed automatically from platform data. The company triggers the sharing; it enters no figures.