Nine of twelve services reviewed is 75%. Ten of fourteen is about 71%. The team completed more reviews, yet visibility into its current estate fell. An AppSec scorecard should expose that change and tell leadership what work would improve the situation.
Start with four measures: review coverage, approved open material findings, due fixes positively reassessed, and investigations resolved. Define each population before calculating it. The worked example below provides the underlying records, so every headline can be reconstructed. All services, records and thresholds are fictional teaching examples, not product results or industry benchmarks.
NIST SP 800-55 Volume 1 addresses selecting measures and evaluating their quality. Volume 2 addresses the measurement program. The four measures here are an editorial choice for this team's decisions, not a prescribed NIST scorecard.
Agree on the rules before seeing the result
The October snapshot closes at 18 October 2026, 17:00 UTC. September's snapshot closed at 30 September, 17:00 UTC. Coverage means completion of the team's declared source-and-policy review on a named revision in the current quarterly review cycle. It does not mean all requirements passed or every deployed instance was tested. This is a period-review measure: a later deployment does not erase the historical review, but its revision no longer inherits the review conclusion without a documented change-impact check. Track services with unassessed material changes separately; use a current-revision numerator if the decision requires current deployment assurance.
| Measure and source fields | Inclusion rule | Owner and illustrative decision trigger |
|---|---|---|
Coverage: service_id, production status, revision, review completion |
Distinct current production services with complete review / signed-off production inventory; partial work stays outside the numerator | Platform inventory owner + AppSec; any unreviewed payment or account-boundary service needs a dated assessment decision |
Open material findings: finding_id, approval, closure state, consequence |
Approved distinct findings still open in the declared code-review scope; this team's material filter is customer-boundary failure or unauthorized money movement | Security lead; each such finding needs an engineering response and owner |
| Due fix verification: frozen finding IDs/due dates, new revision, positive reassessment | Due-cohort IDs with positive code reassessment by cutoff / all five IDs frozen on 1 October | Engineering lead; any merged fix waiting more than two working days gets a reviewer-capacity check |
| Investigation resolution: investigation ID, opened time, supported disposition | Evidence-backed approvals or rejections received during October / investigations open at start plus new ones | AppSec lead; unresolved items must identify a missing fact or a capacity bottleneck |
The working-day trigger is this team's staffing choice. It is not a remediation deadline recommended for every organization. Production deployment remains a separate field: positive code reassessment does not erase exposure from an older running artifact.
Read the service inventory behind 10/14
These are all fourteen services, grouped only where their states match. The range S01–S09 means nine distinct inventory rows; it is not one large service.
| Service IDs and names | September state | October state | Evidence or next work |
|---|---|---|---|
| S01 checkout, S02 billing, S03 identity, S04 exports, S05 support, S06 catalog, S07 notifications, S08 search, S09 webhooks | Reviewed | Reviewed, revisions retained | Nine completed review records remain within the declared cycle |
| S10 partner gateway | Not reviewed | Reviewed | Review R10 completed 12 October |
| S11 analytics worker | Not reviewed | Not reviewed | Assigned review slot next cycle |
| S12 migration worker | Not reviewed | Partial | Missing effective service-role policy; platform owner must supply it |
| S13 payments adapter | Not yet production | Not reviewed | Deployed 8 October; review packet and owner ready, reviewer not assigned |
| S14 import worker | Not yet production | Not reviewed | Deployed 10 October; inventory complete, assessment deferred |
September: nine complete out of twelve. October: those nine plus S10, out of fourteen. S12 is not rounded up because some files were examined. S13 and S14 enter the denominator when they enter production, not when security gets around to reviewing them.
This ledger distinguishes two different causes of low coverage. S12 needs platform evidence; adding another analyst will not conjure its effective policy. S13 needs reviewer capacity; repeatedly requesting an inventory already supplied wastes time. The same 71% headline can conceal either problem unless the gap rows travel with it.
Reconstruct the finding and investigation numbers
The frozen due cohort is F01–F05. F06 is approved but due next month. All six meet the example's material-impact filter. This is the complete approved finding population for the example; candidate alerts are elsewhere.
| ID / service | Code state at cutoff | Deployment evidence | In October due cohort? |
|---|---|---|---|
| F01 / S01 | Positive reassessment 10 October | Corrected artifact confirmed | Yes |
| F02 / S02 | Positive reassessment 12 October | Production mapping missing | Yes |
| F03 / S03 | Merged 13 October; waiting for reviewer | Not yet established | Yes |
| F04 / S04 | Inconclusive: control moved, effective policy missing | Unknown | Yes |
| F05 / S04 | No correction | Affected artifact mapped | Yes |
| F06 / S13 | Newly approved 15 October | Affected artifact mapped | No; due November |
Due code fixes: F01 and F02 give 2/5 = 40%. Open material code findings: F03–F06 give 4, across S03, S04 and S13: 3 services. Report F02 beside them as a deployment uncertainty; calling only four production exposures open would exceed the evidence. These definitions deliberately separate code closure from deployed exposure.
The investigation register has five IDs. I01 and I02 were open on 1 October; I03–I05 opened during the period. I01 was approved on 15 October and became F06. I02 was rejected with control evidence on 16 October. I03 needs deployment mapping, I04 needs a service-role policy, and I05 has a complete packet but awaits review.
Thus investigation resolution is 2/5 = 40%, with 3 unresolved. Approval and rejection both resolve an investigation, but neither is a fix. I01 becoming F06 increases known open risk; that does not mean the investigation process failed. It produced an actionable conclusion.
Publish the compact scorecard
APPSEC SCORECARD — illustrative cutoff 18 October 2026, 17:00 UTC
Coverage: 10/14 complete in current review cycle (prior 9/12).
Inventory +2 production services; completed reviews +1.
Gaps: S12 policy missing; S13 ready but unstaffed; S11/S14 deferred.
Known open material code findings: 4 across 3 services, F03–F06.
Separate production uncertainty: code-fixed F02 lacks deployment mapping.
Due code fixes: 2/5 positively reassessed; only 1 confirmed deployed.
Investigations resolved: 2/5 (1 approved, 1 rejected); 3 remain open.
Decision: platform owner supplies S12 migration-worker policy evidence,
separately supplies F04 exports-policy evidence, and resolves I04's named
service-role request. Shared dependency is not established. Supply F02
deployment mapping; AppSec staffs S13 and clears F03's review wait.
Named owners and dates remain in the linked working registers.
The platform work and reviewer work are distinct assignments. If only one analyst-day is available, the leader should choose explicitly between reviewing S13 and clearing F03, using their consequences and expected effort. A percentage cannot make that choice. It can reveal the two competing needs without hiding the evidence dependency.
Use the scorecard to distinguish three bottlenecks
The October measures should lead to different conversations with three owners. Platform needs to provide the missing policy and deployment artifacts. AppSec needs to allocate reviewer time to a ready service and a merged correction. Engineering needs to address the still-present paths and explain any compatibility or release constraints. Sending every row to the same “security backlog” would discard the diagnostic value of the scorecard.
Start with F03. Its merged change is waiting for review, so the next useful unit of work is a bounded reassessment against the original claim and new revision. Asking engineering to open another fix PR will not remove that bottleneck. For F04, the control moved and the effective policy is missing. Another source search may repeat the same uncertainty until the policy owner supplies the current binding. For F05, no correction exists; the owner needs a repair or explicit risk-response decision. The statuses are not merely different colors for the same delay.
Give each measure a short decision note. “Due fixes 2/5” can be followed by “one ready for reassessment, one blocked on policy, one uncorrected.” That explanation is small enough for leadership and specific enough for the responsible teams. It also prevents a percentage target from encouraging the quickest superficial closure instead of the work that changes exposure.
Check whether an apparent trend describes the same population
Suppose November introduces a deeper authorization review method requiring worker and delivery evidence that October's method did not include. A lower completion fraction under the new method does not by itself mean the team performed worse. Label the changed method and either keep separate series or reconstruct comparable history where the evidence allows. Do not backfill a pass for old reviews simply because their dashboard cells were once green.
The same care applies to the material-impact filter. October's filter includes customer-boundary failure and unauthorized money movement. If November adds service-wide availability failures, the open-material count may rise because the definition broadened. That is a useful change in attention, but its effect should be explained alongside newly discovered findings. A leader should be able to separate real new knowledge, new scope and a definition change.
Use counts when the population is small. Moving from two to three verified fixes in a five-item cohort changes the rate from 40% to 60%, a twenty-percentage-point increase caused by one item. Report that item and its evidence. The percentage alone can make a small sample look like a stable performance trend. Likewise, a month with no due findings has no meaningful due-fix percentage; show the zero-sized cohort rather than awarding an automatic perfect rate.
Keep the measures hard to misunderstand
Before publishing, ask a reader to reconstruct three facts from the card: how much of the current estate was reviewed under the declared method, how many supported issues remain unresolved, and what evidence is needed next. If they infer that ten services are secure or that F02 is confirmed fixed in production, adjust the wording. The metric definition should prevent that interpretation without requiring a lengthy oral explanation.
An accountable owner should also inspect a few source records behind each changing number. Check that a new production service entered the inventory, a repeated event did not become another finding, and a closure has the evidence its label promises. This is a data-quality review of the report, not a new security assessment of every application.
Finally, keep the scorecard separate from individual performance rewards. The useful outcome is earlier identification and resolution of material risk with honest coverage. A team that discovers and approves F06 may increase the open count while improving visibility. A team that reports a blocked control accurately may lower an assurance-looking percentage while preventing an unsupported claim. The management response should reward a clearer decision and assign the work that the clearer evidence exposes.
Keep the series honest next month
Save the inventory and due-cohort membership with each snapshot. If F05 receives an exception, it remains in October's five-item denominator and outside the verified-fix numerator. If a service retires, retain its retirement evidence before reducing the next inventory. If the review method changes, label the break or recalculate comparable history; do not join incompatible percentages into one reassuring line.
For a quick audit, trace F02 into both the code-fix numerator and the deployment-unknown note. Trace S12 out of the coverage numerator but into its denominator. Trace I01 into resolution and F06, without counting it twice as two vulnerabilities. Those three cross-checks expose the most consequential ambiguities in this example.
Use the remediation cohort guide for closure accounting, the MTTR guide for elapsed time, and the CEO brief when the scorecard reveals a business tradeoff that needs leadership.