Security Requirements (SR) - Software Assessment

Assessment questionnaire for measuring maturity. Answer each question honestly based on current, implemented practices.

v3.0 framing: The canonical source-of-truth for Security Requirements (SR) in the Software domain is ../practices/SR-Software-OnePager.md. Outcome metrics in this questionnaire are reproduced verbatim from that one-pager. Canonical subject and through-lines: ../HAIAMM-v3.0-Framing.md §8.

Security Requirements (SR) - Software Domain

HAIAMM Assessment Questionnaire v3.0

Practice: Security Requirements (SR) Domain: Software Purpose: Assess organizational maturity in authoring and maintaining the AI/HAI Software Requirements Pack, a base set plus per-archetype deltas, and producing a Requirements-Evidence Map (REM) for every software artifact that enters or is active in production. Scoring Model: Evidence + Outcome Metrics (see Scoring Methodology below)

Instructions

Answer each question honestly based on current, implemented practices (not plans or aspirations)
Each question has two components: Evidence (what you did) and Outcome Metrics (how well it worked)
Scoring uses 4 tiers: Fully Mature (1.0), Implemented (0.67), Partial (0.33), Not Implemented (0.0)
Answer progressively, Complete all Level 1 questions before Level 2
Level progression, Achieve ALL questions at a lower level before advancing
Baseline first, Record current metric values before setting targets

Scoring Methodology

Score	Label	Criteria
1.0	Fully Mature	Evidence complete AND ≥3 outcome metrics meet targets
0.67	Implemented	Evidence complete AND 2 outcome metrics meet targets
0.33	Partial	Evidence partially complete AND <2 metrics meet targets
0.0	Not Implemented	No evidence present

Maturity Level 1

Objective: Publish the AI/HAI Software Requirements Pack (base plus per-archetype deltas), wire it into the SM intake gate, and produce a Requirements-Evidence Map for every artifact entering production.

Question 1: Author the base AI/HAI Software Requirements Pack

Q1.1: Does a published, versioned AI/HAI Software Requirements Pack exist containing a base set (target ≤20 requirements) with every requirement tagged to at least one TA-Software archetype threat and one PC-Software priority-compliance item, and are reviewers selecting from the pack rather than drafting requirements per artifact at intake?

Evidence Required: - [ ] Base requirements pack document published in the requirements registry with a version number and a named owner - [ ] Pack covers minimum base categories: identity/auth, data boundary, logging, agent permissions, output integrity, disclosure, and failure modes - [ ] Each requirement row carries: ID, statement, rationale (threat tag + compliance tag), evidence source, test method, and acceptance criterion - [ ] REM (Requirements-Evidence Map) template exists and is linked from the SM intake checklist - [ ] REM template includes columns for: Met / Met-with-compensating-control / Gap-accepted / Not-applicable, evidence citation, gap owner, gap expiry, and compensating-control description - [ ] Accepted-gaps register exists with named owner and expiry date per row - [ ] Pack-version control record shows version, change date, and change summary for each revision

Outcome Metrics: | Metric | Baseline | Current | Target | Met? | Notes | |--------|----------|---------|--------|------|-------| | Base + archetype requirements packs published | 0 / 8 documents | /8 | 8 / 8 (base + 7 archetype deltas) | ☐ | Requirements registry | | % new AI/HAI software approvals with a completed REM | measure | % | 100% | ☐ | SM intake ticket + REM artifact | | % active AI/HAI software artifacts in inventory with a current-year REM | measure | % | ≥90% | ☐ | Inventory × REM artifacts | | % of pack requirements tagged to a TA-Software archetype threat and a PC-Software priority-compliance item | measure | % | 100% | ☐ | Pack metadata | | Accepted-gap aging (median age of open accepted-gap rows) | measure | ___ days | ≤90 days | ☐ | REM backlog |

Metric Collection Guidance: - Packs published: Count published documents in the requirements registry: 1 base + 7 archetype deltas (LLM-integrated app, agent, RAG, fine-tune/training, eval harness, model-serving service, classical ML). Source: requirements registry index. - % new approvals with REM: Query SM intake tickets closed in the last 90 days; count those with a linked REM artifact. Formula: REMs on file / total new approvals × 100. - % active artifacts with current-year REM: Cross-reference SM inventory against REM artifact store; flag artifacts with no REM dated in the current calendar year. Formula: artifacts with current-year REM / total active artifacts × 100. - % requirements tagged: Inspect pack metadata fields; count requirements with both a TA threat tag and a PC compliance tag. Formula: tagged requirements / total requirements × 100. - Accepted-gap aging: Query the accepted-gaps register; compute median calendar days from gap-open date to today for all currently open rows. Source: REM backlog or gap register.

Answer: - ☐ Fully Mature (Evidence complete + ≥3 metrics meet targets) - ☐ Implemented (Evidence complete + 2 metrics meet targets) - ☐ Partial (Evidence partially complete + <2 metrics meet targets) - ☐ Not Implemented (No evidence of a published requirements pack)

Evidence Location: __ Validation Date: __ Notes: ___

Question 2: Author per-archetype requirement deltas

Q2.1: Have per-archetype requirement deltas been authored and published for all seven software archetypes (LLM-integrated app, autonomous agent, RAG pipeline, fine-tuning/training workload, eval/red-team harness, model-serving service, classical ML model), and are the correct deltas automatically applied at intake based on the artifact's archetype?

Evidence Required: - [ ] Seven archetype-delta documents (or pack sections) published with version numbers and tagged to TA-Software archetype threats - [ ] Each delta includes minimum-viable scope items specific to its archetype (e.g., tool allowlist for agents, retrieval-source allow-list for RAG, training-data provenance for fine-tune workloads) - [ ] Intake process routes each artifact to base pack + applicable archetype delta(s); routing logic is documented and tested with at least one intake example per archetype - [ ] REM template enforces that archetype-specific delta rows are present and populated for the declared archetype - [ ] Pack-version control record reflects any delta amendments and cross-references the TA-Software archetype threat that drove each change - [ ] Traceability matrix exists linking each delta requirement back to the TA-Software archetype threat model and the PC-Software priority compliance map - [ ] Compensating-controls list documents approved compensating controls for common gap patterns per archetype

Metric Collection Guidance: - Packs published: Same as Q1, verify all seven archetype-delta documents are present in the registry. - % new approvals with REM: Same as Q1, verify that REM rows for the artifact's archetype delta are populated, not only base rows. - % active artifacts with current-year REM: Same as Q1, additionally confirm that archetype delta rows are present in each REM, not only base pack rows. - % requirements tagged: Confirm all delta requirements carry both a TA threat tag and a PC compliance tag; flag any untagged rows. - Accepted-gap aging: Same as Q1, include archetype-delta gap rows in the aging calculation.

Evidence Location: __ Validation Date: __ Notes: ___

Question 3: Wire the pack into the SM intake gate and produce a REM per artifact

Q3.1: Is the requirements pack wired into the SM intake gate so that every AI/HAI software artifact approved for production carries a completed REM, with Met rows citing specific evidence, Gap-accepted rows naming an owner and expiry date, and material-change triggers defined for when the REM must be re-reviewed?

Evidence Required: - [ ] SM intake checklist includes a gate step requiring a completed REM before Sanctioned status is issued - [ ] At least three production REMs on file from the last 90 days, each showing Met / Gap-accepted / Not-applicable rows with evidence citations - [ ] Each Met row in the sample REMs cites a specific artifact (code-review finding, DPA clause, admin-console screenshot, test result reference, architecture-diagram element), not a narrative assertion - [ ] Each Gap-accepted row carries: compensating control description (or "none"), named owner, re-review date (≤90 days from open date at L1), and residual-risk rationale - [ ] REM-population status per artifact is tracked and visible to the pack owner (e.g., a dashboard or registry view showing REM completion % per active artifact) - [ ] Material-change trigger list is documented (model-family swap, new tool addition, new retrieval source, new data class, scope expansion) and included in the intake checklist - [ ] Pack-version control confirms quarterly refresh cadence with at least one refresh on record

Metric Collection Guidance: - Packs published: Confirm the pack registry shows 8/8 documents (base + 7 archetype deltas) with current version numbers. - % new approvals with REM: Pull SM intake ticket list for last 90 days; confirm each Sanctioned status was preceded by a linked REM artifact. - % active artifacts with current-year REM: Run inventory × REM cross-reference; compute completion ratio. - % requirements tagged: Spot-check 10 REM rows across 3 artifacts; confirm each row cites a specific evidence artifact, not a narrative. - Accepted-gap aging: Confirm median open-gap age is within ≤90 days; flag any gap without a named owner or expiry.

Evidence Location: __ Validation Date: __ Notes: ___

Maturity Level 2

Objective: Replace qualitative requirements with quantitative, SLA-bound, and binary-evidence conditions; calibrate the requirements pack per risk tier; and validate REM evidence continuously for Critical and High-tier artifacts.

Question 4: Quantitative and binary requirement pack

Q4.1: Do 100% of pack requirements carry a quantitative or binary evidence condition, with every SLA (retention days, kill-switch response time, drift-detection threshold, secrets-scan result) and binary state (no-train toggle confirmed, tool allowlist verified, EU AI Act Art. 26 clause present) specified, and has all qualitative "reasonable" and "appropriate" language been removed from the pack?

Evidence Required: - [ ] Requirements pack shows no qualitative language ("reasonable," "appropriate," "sufficient") in any requirement statement; all language is measurable or binary - [ ] Logging retention requirement specifies exact retention periods by data class and regulation (e.g., prompt/completion logs ≥12 months; admin-audit logs ≥24 months) - [ ] No-train assertion requirement is binary: admin-console setting confirmed OFF + screenshot on file + re-verification cadence documented - [ ] Kill-switch requirement is binary: synchronous halt mechanism tested quarterly; ≤5-minute halt-to-full-stop SLA with last test date and result on file - [ ] REM (Requirements-Evidence Map) template is updated to reflect the quantitative conditions; each row's evidence field maps to the specific SLA or binary predicate - [ ] REM-population status per artifact shows quantitative evidence citations (not narrative) for all Met rows in Critical/High-tier artifacts - [ ] Pack-version control log shows the quantitative update was a tracked amendment with a version bump

Outcome Metrics: | Metric | Baseline | Current | Target | Met? | Notes | |--------|----------|---------|--------|------|-------| | % requirements with quantitative or binary evidence condition | measure | % | 100% | ☐ | Requirements pack | | % Critical-tier REMs re-validated against observed reality in last 90 days | measure | % | ≥95% | ☐ | REM validation log | | Accepted-gap aging, median age of Critical-tier open gaps | measure | ___ days | ≤60 days | ☐ | Gap register | | % Critical-tier artifacts with EU AI Act Art. 26 full deployer-duty checklist evidence in the REM | measure | % | 100% | ☐ | Compliance view | | % tier-appropriate pack overlay applied (Critical full depth, Low base only) | measure | % | 100% | ☐ | SM intake × REM artifact |

Metric Collection Guidance: - % requirements quantitative/binary: Count requirements with a measurable SLA or explicit binary predicate vs. total requirements. Source: requirements pack document; manual review or structured-schema parse. - % Critical-tier REMs re-validated: Count Critical-tier artifacts whose REM validation log shows a re-validation run (not self-attestation alone) in the last 90 days. Formula: re-validated Critical-tier artifacts / total Critical-tier artifacts × 100. - Accepted-gap aging (Critical): Filter gap register to Critical-tier rows; compute median calendar days open. Source: gap register with tier field. - % Critical-tier with Art. 26 checklist: Count Critical-tier artifact REMs that include the EU AI Act Art. 26 full deployer-duty checklist appendix. Formula: Critical-tier REMs with Art. 26 appendix / total Critical-tier artifacts × 100. - % tier-appropriate overlay applied: Sample 10 intake tickets across tiers; verify Critical-tier received full depth and Low-tier received base pack only. Formula: correctly-tiered intakes / sample size × 100.

Evidence Location: __ Validation Date: __ Notes: ___

Question 5: Per-tier requirement depth

Q5.1: Has a per-tier pack overlay been published and enforced at SM intake, with Critical-tier artifacts receiving the full pack plus executive sign-off and a 60-day accepted-gap SLA, and Low-tier artifacts receiving base pack only on a fast-track REM process?

Evidence Required: - [ ] Per-tier pack overlay document published showing Critical / High / Medium / Low tier treatment matrices with distinct requirement depth and gap-aging SLAs - [ ] Critical-tier overlay includes: full base pack + all applicable archetype deltas; executive sign-off requirement; EU AI Act Art. 26 full deployer-duty checklist as a discrete REM appendix; 60-day accepted-gap aging SLA; quarterly REM re-validation - [ ] SM intake routing logic enforces tier-appropriate depth (intake ticket records the tier assignment and the pack overlay version applied) - [ ] Accepted-gaps register is tiered: Critical-tier gaps are flagged when approaching the 60-day escalation threshold, with pre-deadline notification to the named owner - [ ] REM-population status per artifact is visible by tier, with Critical-tier completion tracked separately from lower tiers - [ ] Pack-version control shows the per-tier overlay was versioned and announced to the reviewer community - [ ] Traceability matrix confirms Critical-tier REM rows link EU AI Act Art. 26 deployer duties to specific evidence artifacts, not vendor assertions

Metric Collection Guidance: - % requirements quantitative/binary: Confirm no regressions from Q4, all requirements remain quantitative/binary after the tier overlay was applied. - % Critical-tier REMs re-validated: Same as Q4, verify the re-validation cadence is operating, not just scheduled. - Accepted-gap aging (Critical): Confirm no Critical-tier gap has exceeded 60 days without a documented escalation record naming the program sponsor. - % Critical-tier with Art. 26 checklist: Verify the Art. 26 appendix is complete in every Critical-tier REM. - % tier-appropriate overlay applied: Pull last 30 days of intake tickets; verify tier assignment and pack overlay version are recorded on each ticket.

Evidence Location: __ Validation Date: __ Notes: ___

Question 6: Continuous REM-evidence validation

Q6.1: Are Critical-tier REMs re-validated against observed reality at least quarterly and High-tier at least semi-annually, with validation deltas routed to IM-Software as findings and no Critical-tier accepted gap aging beyond 60 days without documented escalation?

Evidence Required: - [ ] REM validation log exists and shows at least one completed validation run for every Critical-tier artifact in the last 90 days, using observable reality checks (not self-attestation) - [ ] Validation method documented: stratified sample of REM rows per artifact, at least one row per base category (identity/auth, data boundary, logging, agent permissions, output integrity, disclosure, failure modes), verified against current observable state - [ ] Validation deltas (row claimed Met but evidence fails re-validation) are routed to IM-Software as findings with severity tags and remediation SLAs matching the artifact's tier - [ ] Accepted-gaps register shows no Critical-tier gap past 60 days without a documented escalation record naming the program sponsor and the escalation date - [ ] REM-population status per artifact reflects the last validation date and validation outcome for each Critical/High-tier artifact - [ ] Pack-version control records any requirement amendments triggered by validation findings - [ ] IR-Software feedback loop is documented: IR findings for requirements covered by the pack generate a REM row re-review flag; findings are not closed until the REM row reflects current state

Metric Collection Guidance: - % Critical-tier REMs re-validated: Pull REM validation log; count Critical-tier artifacts with a validation run recorded in the last 90 days using observable-reality checks (not self-report). - Accepted-gap aging (Critical): Confirm the 60-day SLA is enforced; spot-check any gap older than 60 days for an escalation record; zero exceptions without documented escalation. - Validation delta routing: Confirm IM-Software backlog contains findings originating from REM validation deltas in the last 90 days; findings should reference the specific REM row and artifact. - Art. 26 checklist: Confirm the checklist evidence is current (not a legacy document predating the current model version or deployment configuration). - Tier overlay compliance: Confirm intake routing is still enforcing tier-appropriate depth.

Evidence Location: __ Validation Date: __ Notes: ___

Maturity Level 3

Objective: Express the AI/HAI Software Requirements Pack as a machine-readable artifact, automate REM-evidence validation from CI/CD attestation and runtime signals, and contribute to industry-standard AI software security requirements bodies.

Question 7: Machine-readable pack and CI/CD attestation

Q7.1: Is the AI/HAI Software Requirements Pack expressed in a machine-readable schema (JSON or YAML) with each requirement carrying an evidence type, an acceptance predicate, and a tier-applicability field, and do Critical-tier artifact deploys fail the CI/CD pipeline when a REM requirement check fails?

Evidence Required: - [ ] Machine-readable requirements pack published (JSON or YAML schema); each requirement has: ID, machine-readable evidence type (log-query / config-check / test-result-reference / manual-attestation), acceptance predicate, and tier applicability field - [ ] CI/CD pipeline for Critical-tier artifacts includes automated REM checks at deploy time covering base pack categories: identity/auth, data boundary, logging, agent permissions, output integrity, disclosure, failure modes - [ ] Failed REM check blocks the deploy for Critical-tier artifacts; evidence of at least one blocked deploy or a test of the block is on file - [ ] Passed REM checks write a signed attestation to the REM record; attestation log is queryable - [ ] REM-population status per artifact is updated automatically from CI/CD attestation results for automated evidence types - [ ] Pack published under a permissive license with an external adoption tracking mechanism (forks, citations, or downloads logged) - [ ] Pack-version control aligns the public version with the internal version; no version lag exceeding one quarter

Outcome Metrics: | Metric | Baseline | Current | Target | Met? | Notes | |--------|----------|---------|--------|------|-------| | % Critical-tier REM requirements with automated CI/CD attestation at deploy time | measure | % | ≥80% | ☐ | CI/CD pipeline attestation log | | % REM evidence rows auto-validated (vs. manual-only) | measure | % | ≥70% | ☐ | Validation telemetry | | CI/CD deploy blocks triggered by failed Critical-tier REM check | measure | ___ | tracked; zero silent failures | ☐ | Pipeline telemetry | | Pack adoption (forks, citations, downloads of published artifact) | 0 | ___ | tracked, trending up | ☐ | External telemetry | | Industry-standard contributions per year | 0 | ___ | ≥2 | ☐ | Contribution log |

Metric Collection Guidance: - % Critical-tier requirements with CI/CD attestation: Count Critical-tier REM requirement rows with an automated CI/CD check vs. total Critical-tier requirement rows. Formula: automated Critical-tier rows / total Critical-tier rows × 100. - % REM rows auto-validated: Count all REM rows where the last validation was performed by an automated check vs. total rows. Formula: auto-validated rows / total rows × 100. - CI/CD deploy blocks: Count blocked deploys in the last 90 days where the block was triggered by a failed Critical-tier REM check; confirm zero silent failures. - Pack adoption: Query external telemetry (GitHub stars/forks, download counters, citation tracking) for the published pack; confirm an upward trend over a 3-month window. - Industry-standard contributions: Count substantive contributions (submitted schema, requirement clauses, commentary) to OpenSSF AI / OWASP SAMM AI / NIST AI RMF Playbook / ISO AI security standards work in the last 12 months.

Evidence Location: __ Validation Date: __ Notes: ___

Question 8: Automated REM-evidence validation from runtime signals

Q8.1: Are ≥70% of REM evidence rows auto-validated via CI/CD signals, runtime monitoring (ML-Software), and admin-console API ingestion, with automation error-rate monitored and human review reserved for exceptions, novel clauses, and accepted-gap escalations?

Evidence Required: - [ ] REM validation pipeline is subscribed to ML-Software monitoring outputs (logging completeness signal, drift detection signal) and routes failures to the correct REM rows - [ ] IM-Software incident records feed the REM validation pipeline: post-incident reviews touching a pack requirement auto-flag the relevant REM rows for re-validation - [ ] SM inventory change events (tier upgrade) auto-trigger a full REM re-validation run under the new tier's requirements depth - [ ] Automation error-rate (false-positive and false-negative gate failures) is monitored; a defined threshold triggers human review of the affected check - [ ] Human review queue is bounded: only novel clauses, edge-case N/A justifications, and accepted-gap escalations remain for manual handling - [ ] REM-population status per artifact reflects auto-validated rows separately from manual-attestation rows; staleness of each auto-validated row is tracked - [ ] Pack-version control records amendments triggered by automation findings

Metric Collection Guidance: - % auto-validated rows: Pull validation telemetry; count rows with an auto-validation result in the last 90 days vs. total active REM rows. Confirm the 70% target is met across both Critical and High-tier artifacts. - Automation error-rate: Query the pipeline's false-positive log and false-negative log; threshold for human review of the affected check should be documented. - Human review queue: Confirm the queue is bounded; verify that no manual-attestation rows have been pending for more than the defined SLA without action. - CI/CD deploy blocks: Confirm the pipeline is still enforcing the gate; zero silent failures means zero deploys where a Critical-tier check failed but the deploy proceeded. - ML-Software signal subscription: Verify that the REM pipeline has received and processed at least one drift-detection or log-completeness signal in the last 90 days.

Evidence Location: __ Validation Date: __ Notes: ___

Question 9: Standards contribution

Q9.1: Has the program contributed at least two substantive artifacts per year to recognized standards bodies, with contributions publicly documented and traceable to adoption in OpenSSF AI, OWASP SAMM AI, NIST AI RMF Playbook, or ISO AI security standards work?

Evidence Required: - [ ] Contribution log lists at least 2 substantive contributions in the last 12 months with: body name, contribution type, submission date, and a link or reference to the external artifact - [ ] Contributions are legally vetted (internal legal review record on file) and anonymized or attributed per the org's disclosure policy - [ ] At least one contribution is a machine-readable artifact (JSON schema, YAML schema, or equivalent) rather than commentary only - [ ] External adoption is tracked: at least one contribution has a confirmed path to adoption (working group vote, draft inclusion, or citation in a published document) - [ ] Pack published under a permissive license with version aligned to the internal version; no version lag exceeding one quarter - [ ] REM schema published alongside the pack as an open artifact; schema version matches the internal REM template - [ ] Contribution pipeline has ≥2 contributions in-flight at any given time

Metric Collection Guidance: - Industry-standard contributions: Count contributions in the last 12 months in the contribution log; confirm each has a body name, submission date, and external reference link. Minimum 2 to meet target. - Pack adoption: Confirm external telemetry shows an upward trend in forks, citations, or downloads; a flat or declining trend is a gap signal. - Contribution pipeline health: Confirm ≥2 contributions are actively in-flight (submitted or under working-group review), not only completed. - Version alignment: Check that the public pack version tag matches the current internal version tag. - CI/CD blocks and auto-validation: Confirm the L3 automation goals from Q7 and Q8 remain met.

Evidence Location: __ Validation Date: __ Notes: ___

Summary Scorecard

Question	Activity	Score
Q1	L1-A: Base requirements pack	☐ 1.0 / ☐ 0.67 / ☐ 0.33 / ☐ 0.0
Q2	L1-B: Per-archetype deltas	☐ 1.0 / ☐ 0.67 / ☐ 0.33 / ☐ 0.0
Q3	L1-C: SM intake gate + REM per artifact	☐ 1.0 / ☐ 0.67 / ☐ 0.33 / ☐ 0.0
Q4	L2-A: Quantitative and binary pack	☐ 1.0 / ☐ 0.67 / ☐ 0.33 / ☐ 0.0
Q5	L2-B: Per-tier requirement depth	☐ 1.0 / ☐ 0.67 / ☐ 0.33 / ☐ 0.0
Q6	L2-C: Continuous REM-evidence validation	☐ 1.0 / ☐ 0.67 / ☐ 0.33 / ☐ 0.0
Q7	L3-A: Machine-readable pack + CI/CD attestation	☐ 1.0 / ☐ 0.67 / ☐ 0.33 / ☐ 0.0
Q8	L3-B: Automated REM-evidence from runtime signals	☐ 1.0 / ☐ 0.67 / ☐ 0.33 / ☐ 0.0
Q9	L3-C: Standards contribution	☐ 1.0 / ☐ 0.67 / ☐ 0.33 / ☐ 0.0
Total		___ / 9.0

Achieved Maturity Level: ☐ Not Started / ☐ Level 1 / ☐ Level 2 / ☐ Level 3

Document Version: HAIAMM v3.0 Practice: Security Requirements (SR) Domain: Software Questionnaire Authored: 2026-05-15 Author: Verifhai

Instructions:

Answer based on current practices, not plans
“Yes” requires documented evidence
Complete all Level 1 questions before Level 2
Partial implementation = “No”

↓ Download as Markdown