Critical Evaluation

Reading frame

This evaluation reads the research design module against its companion, the draft gap analysis module and the underlying spreadsheet instrument that operationalizes the methodology. The framework is conceptually strong and the research design module, in isolation, is well-written. The most important finding sits at the seam between the research design module and the gap analysis module — and it needs to be resolved before the manuscript can be submitted.

▲ Critical issue · the research design and gap analysis modules do not describe the same instrument

Recommendation

Declare the research design module canonical. Rewrite the gap analysis module to mirror its three-stage flow exactly, dropping the lifecycle-evaluation expansion (or moving it to the discussion section as a future extension). Treat the D1–D10 domain grouping as a presentation layer in the heatmap, not as an analytical layer. Rebuild the xlsx instrument so its scoring matches the research design module (MIL 0–3, Priority Quota with the published thresholds).

Methodological strengths to keep

Clean separation of control maturity from governance maturity

The decision to isolate control maturity from governance maturity — using ISO 37004 as the assumed baseline — is genuinely innovative. It solves a confound that plagues most maturity studies, where good corporate governance is silently treated as evidence of good operational controls. The two are not the same; the framework's analytical leverage comes from refusing to conflate them.

Unit of analysis isolated to the control, tested against four archetypes

Scoring each control independently for each deployment archetype is the right move. It bypasses the common trap of assuming that a well-governed organization automatically possesses well-functioning AI controls, and it lets the instrument surface the fact that the same control behaves very differently under direct external use than under fine-tuned internal deployment.

1009 LTD as a methodological anchor

Using a documented, published, simulated enterprise (rather than abstract generalizations or a confidential client) is methodologically clever. It solves the confidentiality problem that limits most empirical AI security work and gives the methodology a reproducible reference scenario. Since 1009.lt is already a live artifact with twelve documented policies, this is real, not aspirational.

Prompt injection and shadow AI special treatments

Both special treatments are theoretically grounded. Citing Geng et al.'s structural argument — that the LLM's inability to cleanly distinguish instructions from data is what makes prompt injection a non-removable control problem — anchors the methodological decision in a position-paper-grade insight, not in convenience. The shadow AI treatment (Waters-Lynch et al., Silic et al.) similarly anchors it as a governance-layer problem distinct from the technical attack surface.

Methodological transparency about generative AI use

Section 3.8 is one of the strongest parts of the module. The IIA Three Lines persona ("punctilio of an independency"), explicit alignment with the EC Living Guidelines, the published Prompt Library on GitHub/Zenodo, and the human- validation accountability statement are all what a methodologically literate reviewer would want to see. This section alone differentiates the paper from typical "we used ChatGPT" mentions.

Issues a peer reviewer is likely to flag

Numerical inconsistencies in Section 3.3

Section 3.3 says "Events resemble the abovementioned seven risk domains" but then enumerates eight (data poisoning, model poisoning, adversarial examples, model evasion, confidentiality attacks, model flaws, prompt injection, shadow AI). The xlsx instrument confirms eight. The number needs to be reconciled.

The MIL scale and Priority Quota thresholds do not reconcile arithmetically

MIL 0–3 means maximum Capability Gap is 3. Urgency 1–5 means the simple product Urgency × Gap maxes out at 15, in integer steps. But the threshold table specifies decimal precision (> 8.0, 6.1–8.0, 4.1–6.0), implying the Priority Quota is a weighted aggregate of the four criteria, not a simple integer product. The formula in Section 3.5 says "Capability Gap × Urgency Level" but the bands imply something else. A worked example with one risk-control pair would resolve this.

C2M2's Approach / Management split mapped to the four criteria is post-hoc

Coverage and specificity are not natural "Approach" indicators in the original C2M2 formulation — Approach is about the completeness with which a practice is performed, while Coverage is about scope and Specificity is about granularity. Operationalizability fits "Management" reasonably well; Adaptability arguably belongs to neither in the native C2M2 sense. Either justify the mapping more explicitly (with a paragraph on why the bent C2M2 still inherits the Approach/Management framing) or drop the Approach/Management framing and present the four criteria as a flat rubric.

Section 3.6 is missing

The module jumps from Section 3.5 to Section 3.7. Likely an editing remnant.

No reliability or inter-rater validation strategy

Section 3.7 acknowledges future empirical validation, but for the framework to land as an "analytical instrument" rather than one author's interpretation, even a small pilot inter-rater study — two independent raters scoring a 20-pair subset, Cohen's κ reported — would substantially strengthen the paper now. Without it, every score is a single-rater judgment, and the published Prompt Library mitigates but does not solve this.

Scope limitation buried in footnote 1

"Limited to organizational and technical controls to create a link with GAISO" is a defensible scope decision, but it excludes ISO 27002:2022's eight People controls and fourteen Physical controls. This belongs in the main text with explicit rationale — especially because shadow AI (a flagship risk domain in Section 3.3) is fundamentally a people-control problem and is therefore evaluated through a structurally limited surface. The current module acknowledges this only implicitly.

Placeholders that must be resolved before submission

• Every citation block ends with [check literature].
• The Prompt Library is "uploaded to [GitHub/Zenodo]" without a link.
• The "Gemini 3.1 Pro top of HLE leaderboard" claim needs a dated snapshot URL.
• Footnote 5 has [prompt] as a placeholder.

Strengthening recommendations, prioritized

1. Reconcile the research design module and the gap analysis module. Declare the research design module canonical; rewrite the gap analysis module to match the three-stage flow exactly. Rebuild the xlsx so its scale matches the published MIL 0–3 / Priority Quota thresholds. Blocking.
2. Resolve the arithmetic of Priority Quota. Add a worked example with one risk-control pair showing how 4 criteria, MIL, Capability Gap, Priority Quota, priority band, end to end. High.
3. Reconcile the risk-domain count (7 vs 8) in Section 3.3. Quick fix.
4. Insert the missing Section 3.6. Quick fix.
5. Add a brief inter-rater pilot on a 20-pair subset, with Cohen's κ. Even modest results substantially strengthen the methodological claim. Medium effort, high return.
6. Move the People/Physical scope rationale from footnote to main text, and tie it explicitly to shadow AI's analytical treatment via the Accountability Gap classification. Quick fix.
7. Resolve all bracketed placeholders (citations, GitHub/Zenodo link, HLE leaderboard snapshot URL, prompt references). Quick fix but essential for submission.
8. Justify or simplify the Approach / Management mapping of the four criteria. Medium effort.