Security Requirements (SR) - Processes 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 Processes domain is ../practices/SR-Processes-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) - Processes Domain

HAIAMM Assessment Questionnaire v3.0

Practice: Security Requirements (SR) Domain: Processes Purpose: Assess organizational maturity in authoring and maintaining the AI/HAI Workflow Requirements Pack, a base set plus per-archetype deltas, and producing a Requirements-Evidence Map (REM) for every AI/HAI-embedded workflow entering 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 Workflow Requirements Pack (base plus per-archetype deltas), wire it into the SM intake gate, and produce a Requirements-Evidence Map for every workflow entering production.

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

Q1.1: Does a published, versioned AI/HAI Workflow Requirements Pack exist containing a base set (target ≤20 requirements) covering human oversight (Art. 14)/Art. 50 disclosure/decision logging/override audit trail/output-integrity SLA/reviewer-capacity/affected-persons rights/DPIA-FRIA/fallback, with every requirement tagged to at least one TA-Processes archetype threat and one PC-Processes priority-compliance item?

Evidence Required: - [ ] Base requirements pack document published in the requirements registry with a version number and a named owner - [ ] Pack covers minimum base categories: human oversight design (EU AI Act Art. 14, HITL placement, gate depth, override authority, fallback), disclosure (EU AI Act Art. 50, how and when affected persons are informed), decision logging (what drove each decision, when, on whose data, which model/version, which human reviewed), override audit trail (reviewer identity, override direction, rationale, timestamp, AI output overridden), output-integrity SLA (drift-detection baseline, alert threshold, human-review trigger), reviewer-capacity SLA (queue depth, reviewer ratio, review time, capacity-breach procedure), affected-persons rights (GDPR Arts. 15–22 access, explanation, contestation path), DPIA/FRIA evidence, and fallback/kill-switch - [ ] 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; template includes Met / Met-with-compensating-control / Gap-accepted / Not-applicable columns with 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 - [ ] Cross-domain linkage documented: workflow REM cross-references underlying Software, Data, and Infrastructure component REMs

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 workflow approvals with a completed REM | measure | % | 100% | ☐ | SM intake ticket + REM artifact | | % active AI/HAI workflows in inventory with a current-year REM | measure | % | ≥90% | ☐ | Inventory × REM artifacts | | % of pack requirements tagged to a TA-Processes archetype threat and a PC-Processes 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 (decision pipeline, customer-facing flow, HITL chain, back-office augmentation, approval/review workflow, content-generation workflow, knowledge-management workflow). Source: requirements registry index. - % new workflow 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 workflow approvals × 100. - % active workflows with current-year REM: Cross-reference SM inventory against REM artifact store; flag workflows with no REM dated in the current calendar year. Formula: workflows with current-year REM / total active workflows × 100. - % requirements tagged: Count requirements with both a TA threat tag and a PC compliance tag. Formula: tagged requirements / total requirements × 100. - Accepted-gap aging: Compute median calendar days from gap-open date to today for all currently open rows. Source: accepted-gaps 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 workflow 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 workflow archetypes (decision pipeline, customer-facing flow, HITL chain, back-office augmentation, approval/review workflow, content-generation workflow, knowledge-management workflow), and are the correct deltas automatically applied at intake?

Evidence Required: - [ ] Seven archetype-delta documents (or pack sections) published with version numbers and tagged to TA-Processes archetype threats - [ ] Each delta includes minimum-viable scope items specific to its archetype (e.g., Art. 22 lawful-basis requirement for decision pipelines; escalation-to-human path for customer-facing flows; reviewer-UI injection defense for HITL chains; prompt-template versioning for content-generation workflows) - [ ] Intake process routes each workflow 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 delta amendments and cross-references the TA-Processes archetype threat that drove each change - [ ] Traceability matrix links delta requirements back to TA-Processes archetype threat models and PC-Processes priority compliance map (EU AI Act Art. 26/50/14/22, GDPR Art. 22/35, sector-specific rules) - [ ] Compensating-controls list documents approved compensating controls for common gap patterns per archetype

Metric Collection Guidance: - Packs published: Verify all seven archetype-delta documents are present in the registry with current version numbers. - % new approvals with REM: Verify REM rows for the workflow's archetype delta are populated, not only base pack rows. - % active workflows with current-year REM: Confirm archetype delta rows are present in each REM. - % requirements tagged: Confirm all delta requirements carry both a TA threat tag and a PC compliance tag. - Accepted-gap aging: 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 workflow

Q3.1: Is the requirements pack wired into the SM intake gate so that every AI/HAI-embedded workflow approved for production carries a completed REM, with Met rows citing specific evidence, Gap-accepted rows naming an owner and expiry date, cross-domain linkage to Software/Data/Infrastructure REMs, and material-change triggers defined?

Evidence Required: - [ ] SM intake checklist includes a gate step requiring a completed REM before Sanctioned status is issued for the workflow - [ ] At least three production workflow REMs on file from the last 90 days, each showing Met / Gap-accepted / Not-applicable rows with specific evidence citations (process-design document element, HITL gate implementation evidence, admin-console screenshot, test result reference, DPA clause citation, DPIA/FRIA completion date and registry reference) - [ ] Each Met row in the sample REMs cites a specific artifact, 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 - [ ] Cross-domain linkage is operational: the workflow REM cross-references the REMs for underlying Software, Data, and Infrastructure components; at least three workflow REMs on file demonstrating the cross-reference - [ ] Material-change trigger list is documented (AI model swap, HITL restructuring, new data classes, scope expansion, regulatory change) 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 8/8 documents in the registry 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 workflows with current-year REM: Run inventory × REM cross-reference; compute completion ratio. - Cross-domain linkage: Query workflow REM store; count REMs that include explicit cross-references to Software, Data, and Infrastructure REMs. Formula: workflow REMs with cross-domain links / total workflow REMs × 100. - 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 workflows.

Question 4: Quantitative and binary requirement pack

Q4.1: Do 100% of pack requirements carry a quantitative or binary evidence condition, with every SLA (review queue depth, kill-switch response time, drift-detection threshold, log-retention days) and binary state (Art. 22 lawful basis documented, DPIA/FRIA current, override audit trail confirmed, Art. 50 disclosure tested) specified, and has all qualitative "reasonable" and "appropriate" language been removed?

Evidence Required: - [ ] Requirements pack shows no qualitative language in any requirement statement; all language is measurable or binary - [ ] Decision-logging retention requirement specifies exact retention periods by workflow tier and regulation (e.g., decision logs retained ≥24 months for EU AI Act Art. 26 deployer-duty evidence; ≥36 months for FCRA adverse-action workflows) - [ ] Override audit trail completeness requirement is binary: last audit sample of 50 random override records confirmed 100% have reviewer identity, override direction, rationale, timestamp, and AI output reference; audit date on file - [ ] Output-integrity drift alert requirement specifies measurable thresholds: drift-detection baseline established at launch; ≥5% shift in approval/rejection rate or ≥10% shift in score distribution triggers a human review gate within 24 hours; last alert test date and result on file - [ ] Kill-switch test requirement is binary: emergency-halt mechanism tested quarterly; halts workflow within ≤[T] minutes; halt-record confirms no unreviewed AI output acted upon after halt; last test date and result on file - [ ] DPIA/FRIA currency requirement is binary: DPIA/FRIA completed on file, last reviewed within 24 months for Critical-tier workflows; no DPIA/FRIA more than 24 months stale - [ ] REM template updated to reflect quantitative conditions; each row's evidence field maps to the specific SLA or binary predicate - [ ] 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 workflow 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 workflows with EU AI Act Art. 26 full deployer-duty checklist evidence in the REM | measure | % | 100% | ☐ | Compliance view | | % tier-appropriate pack overlay applied | 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. - % Critical-tier workflow REMs re-validated: Count Critical-tier workflow REMs with a re-validation run (not self-attestation alone) in the last 90 days. Formula: re-validated Critical-tier workflow REMs / total Critical-tier workflows × 100. - Accepted-gap aging (Critical): Filter gap register to Critical-tier workflow rows; compute median calendar days open. - % Critical-tier with Art. 26 checklist: Count Critical-tier workflow REMs containing the EU AI Act Art. 26 full deployer-duty checklist appendix with verifiable evidence. Formula: Critical-tier REMs with Art. 26 appendix / total Critical-tier workflows × 100. - % tier-appropriate overlay applied: Sample 10 intake tickets across tiers; verify Critical-tier received full depth (including Art. 26 appendix and DPIA/FRIA evidence) 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 workflows requiring executive sign-off, full Art. 26 deployer-duty checklist, current DPIA/FRIA evidence, a 60-day accepted-gap SLA, and quarterly REM re-validation, and Low-tier workflows receiving base pack only?

Evidence Required: - [ ] Per-tier pack overlay document published showing Critical / High / Medium / Low tier treatment matrices with distinct requirement depth, gap-aging SLAs, and DPIA/FRIA requirements - [ ] 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; DPIA/FRIA evidence required and current; accepted-gap aging SLA of 60 days maximum before mandatory escalation to the program sponsor; quarterly REM re-validation - [ ] SM intake routing logic enforces tier-appropriate depth; intake ticket records tier assignment and pack overlay version applied - [ ] Accepted-gaps register is tiered: Critical-tier gaps are flagged before the 60-day escalation threshold, with pre-deadline notification to the named owner - [ ] REM-population status per workflow is visible by tier, with Critical-tier completion tracked separately - [ ] Cross-domain linkage is re-verified at the same cadence: component REM changes (Software, Data, Infrastructure) that affect workflow requirements are surfaced to the workflow REM owner within 5 business days - [ ] Pack-version control shows the per-tier overlay was versioned and announced to the reviewer community

Metric Collection Guidance: - % requirements quantitative/binary: Confirm no regressions from Q4 after the tier overlay was applied. - % Critical-tier workflow REMs re-validated: Verify the re-validation cadence is operating using observable-reality checks (decision-log volume, HITL queue metrics, kill-switch test, Art. 50 disclosure test, override audit sample). - Accepted-gap aging (Critical): Confirm no Critical-tier workflow 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 with verifiable evidence (not process-owner assertion alone) in every Critical-tier workflow REM. - Cross-domain linkage health: Confirm component REM changes are surfaced to the workflow REM owner within 5 business days; no silent gaps.

Evidence Location: __ Validation Date: __ Notes: ___

Question 6: Continuous REM-evidence validation and cross-domain linkage

Q6.1: Are Critical-tier workflow REMs re-validated against observed reality at least quarterly and High-tier at least semi-annually, with validation deltas routed to IM-Processes as findings, REM auto-revalidation triggered by IR/IM findings and TA pack updates, and cross-domain component REM changes surfaced to workflow REM owners within 5 business days?

Evidence Required: - [ ] REM validation log exists and shows at least one completed validation run for every Critical-tier workflow in the last 90 days, using observable reality checks (decision-log volume and completeness, HITL queue metrics, kill-switch test result, Art. 50 disclosure test, override audit sample) - [ ] Validation method documented: stratified sample of at least one row per base category (human oversight design, disclosure, decision logging, override audit trail, output-integrity SLA, reviewer-capacity, affected-persons rights, DPIA/FRIA, fallback/kill-switch) per workflow - [ ] Validation deltas are routed to IM-Processes as findings with severity tags and remediation SLAs matching the workflow's tier - [ ] Accepted-gaps register shows no Critical-tier workflow gap past 60 days without a documented escalation record naming the program sponsor - [ ] REM auto-revalidation is triggered by: IR-Processes findings (implementation drift), IM-Processes incidents (post-incident reviews touching a pack requirement), and TA-Processes pack updates (new threat intelligence); at least one triggered re-validation is documented in the last 90 days - [ ] Cross-domain linkage health is monitored: no Critical-tier workflow has a component REM change (Software, Data, Infrastructure) that was not surfaced to the workflow REM owner within 5 business days - [ ] Pack-version control records any requirement amendments triggered by validation findings or TA-Processes updates

Metric Collection Guidance: - % Critical-tier workflow REMs re-validated: Pull REM validation log; count Critical-tier workflows with a validation run recorded in the last 90 days using observable-reality checks. Formula: validated Critical-tier workflows / total Critical-tier workflows × 100. - 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-Processes backlog contains findings originating from workflow REM validation deltas in the last 90 days. - Triggered re-validation: Confirm at least one REM re-validation was triggered by an IR/IM finding or TA pack update in the last 90 days (not only by the scheduled cadence). - Art. 26 checklist and DPIA/FRIA: Confirm both are current for all Critical-tier workflows; no legacy documents predating the current workflow configuration.

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 REM validation log or continuous re-validation in place)

Evidence Location: __ Validation Date: __ Notes: ___

Maturity Level 3

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

Question 7: Machine-readable pack and workflow-execution attestation

Q7.1: Is the AI/HAI Workflow Requirements Pack expressed in a machine-readable schema (JSON or YAML), and are Critical-tier workflow REM requirements monitored via workflow-execution attestation with zero Critical-tier workflows operating with failing REM checks undetected?

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 - [ ] Workflow-execution monitoring for Critical-tier workflows includes automated REM checks: decision-log volume and completeness confirmed; HITL queue depth within threshold; override audit trail completeness sampled; kill-switch test result within defined age; drift-detection baseline within alert threshold - [ ] Failed checks for Critical-tier workflows emit an immediate alert to the workflow owner and route a finding to IM-Processes backlog; no silent failures - [ ] Passed checks write a signed attestation to the REM record; attestation log is queryable - [ ] REM-population status per workflow is updated automatically from workflow-execution attestation results for automated evidence types - [ ] Pack published under a permissive license with external adoption tracking (forks, citations, 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 workflow REM requirements with automated execution-time attestation | measure | % | ≥80% | ☐ | Workflow monitoring attestation log | | % REM evidence rows auto-validated (vs. manual-only) | measure | % | ≥70% | ☐ | Validation telemetry | | Workflow-execution alerts triggered by failed Critical-tier REM check | measure | ___ | tracked; zero silent failures | ☐ | Monitoring 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 execution-time attestation: Count Critical-tier workflow REM requirement rows with an automated execution-time check vs. total Critical-tier requirement rows. Formula: automated Critical-tier rows / total Critical-tier rows × 100. - % REM rows auto-validated: Count all workflow REM rows where the last validation was performed by an automated check vs. total rows. Formula: auto-validated rows / total rows × 100. - Workflow-execution alerts: Count alerts triggered in the last 90 days by failed Critical-tier REM checks; confirm zero silent failures (workflows operating with failing checks that did not trigger an alert). - Pack adoption: Query external telemetry for the published pack artifact; confirm an upward trend over a 3-month window. - Industry-standard contributions: Count substantive contributions to ISO/IEC 42005 / OECD AI / sector standards bodies / NIST AI RMF Playbook in the last 12 months.

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 machine-readable pack or workflow-execution attestation)

Evidence Location: __ Validation Date: __ Notes: ___

Question 8: Automated REM-evidence validation from runtime signals

Q8.1: Are ≥70% of workflow REM evidence rows auto-validated via workflow monitoring (ML-Processes), incident feeds (IM-Processes), and SM inventory change events, with automation error-rate monitored and human review reserved for Art. 22 lawful-basis review, DPIA/FRIA currency, novel clauses, and accepted-gap escalations?

Evidence Required: - [ ] REM validation pipeline is subscribed to ML-Processes monitoring outputs (decision-log completeness signal, HITL queue-depth signal, drift-detection output, reviewer-capacity signal) and routes failures to the correct workflow REM rows - [ ] IM-Processes incident records feed the REM validation pipeline: post-incident reviews touching a pack requirement auto-flag the relevant workflow 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 alert failures) is monitored; a defined threshold triggers human review of the affected check - [ ] Human review queue is bounded: Art. 22 lawful-basis reviews, DPIA/FRIA currency confirmations, novel clauses, and accepted-gap escalations are the only items requiring manual handling - [ ] REM-population status per workflow 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 workflow REM rows. Confirm the 70% target is met across both Critical and High-tier workflows. - Automation error-rate: Query the pipeline's false-positive and false-negative logs; threshold for human review should be documented and applied consistently. - Human review queue: Confirm the queue contains only Art. 22 lawful-basis reviews, DPIA/FRIA currency confirmations, novel clauses, and accepted-gap escalations; no standard evidence type should be pending manual review beyond the defined SLA. - Workflow-execution gate: Confirm the monitoring is still enforcing the gate from Q7; zero silent failures means zero Critical-tier workflows operating with a failing check that was not alerted. - ML-Processes signal subscription: Verify the REM pipeline received and processed at least one decision-log or HITL queue-depth signal in the last 90 days.

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 automated REM-evidence validation from runtime signals)

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 ISO/IEC 42005, OECD AI, sector standards bodies, or NIST AI RMF Playbook successor editions?

Evidence Required: - [ ] Contribution log lists at least 2 substantive contributions in the last 12 months with: body name (ISO/IEC 42005, OECD AI, FINRA, CFPB, FDA, EEOC, NIST), contribution type, submission date, and external reference link - [ ] 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 (machine-readable process requirement schema, REM schema for workflow requirements, or process requirement clauses) 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 standard or guidance document) - [ ] Pack + REM schema published under a permissive license with version aligned to the internal version; no version lag exceeding one quarter - [ ] Sector-specific engagement documented where applicable (FINRA model-risk management, CFPB adverse-action, FDA SaMD, EEOC AI bias audit) - [ ] 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. - Contribution pipeline health: Confirm ≥2 contributions are actively in-flight. - Version alignment: Check that the public pack version tag matches the current internal version tag. - L3 automation goals: Confirm the workflow-execution attestation and auto-validation goals from Q7 and Q8 remain met.

Evidence Location: __ Validation Date: __ Notes: ___

Summary Scorecard

Question	Activity	Score
Q1	L1-A: Base workflow 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 workflow + cross-domain linkage	☐ 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 + cross-domain linkage	☐ 1.0 / ☐ 0.67 / ☐ 0.33 / ☐ 0.0
Q7	L3-A: Machine-readable pack + workflow-execution 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: Processes 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