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 Vendors domain is
../practices/SR-Vendors-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.
Practice: Security Requirements (SR) Domain: Vendors Purpose: Assess organizational maturity in authoring and maintaining the AI Vendor Requirements Pack, a base set plus per-archetype deltas, and producing a Requirements-Evidence Map (REM) for every AI vendor the organization approves. Scoring Model: Evidence + Outcome Metrics (see Scoring Methodology below)
| 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 |
Objective: Publish the AI Vendor Requirements Pack (base plus per-archetype deltas), wire it into the intake gate, and produce a requirements-evidence map for every new AI vendor.
Q1.1: Does a published, versioned AI Vendor Requirements Pack exist containing a base set (target ≤20 requirements) covering training-data posture/DPA and AI addendum/subprocessor chain/EU AI Act deployer duties/data residency/no-train probing/Art. 50 disclosure, with every requirement tagged to at least one TA-Vendors archetype threat and one PC-Vendors 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: data handling (no-training default, retention cap, deletion on termination, embeddings/logs retention, data residency), contracting (executed DPA / AI addendum, subprocessor list currency, breach notification SLA ≤72 hours, audit right, exit/data-return clause), identity and access (SSO/SAML or OIDC, admin-role separation, API-key rotation, least-privilege roles), logging and observability (per-user and per-prompt/completion audit logs, export mechanism, retention ≥ org policy), transparency and oversight (model-family disclosure, human-in-the-loop configuration, Art. 50 AI interaction disclosure), and security posture (current SOC 2 Type II or ISO 27001 or equivalent, vulnerability-handling process, pen-test summary or bug-bounty) - [ ] 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 intake gate 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 - [ ] Traceability matrix links each base requirement to EU AI Act deployer duties (Art. 26/50) and GDPR Art. 28 processor obligations
Outcome Metrics: | Metric | Baseline | Current | Target | Met? | Notes | |--------|----------|---------|--------|------|-------| | Base + archetype requirements packs published | 0 / 6 documents | /6 | 6 / 6 (base + 5 archetype deltas) | ☐ | Requirements registry | | % new AI vendor approvals with a completed REM | measure | % | 100% | ☐ | Intake ticket + REM artifact | | % active AI vendors in inventory with a current-year REM | measure | % | ≥90% | ☐ | Inventory × REM artifacts | | % of pack requirements tagged to a TA archetype threat and a 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 + 5 archetype deltas (consumer GenAI, AI-embedded SaaS, AI coding assistant, AI API/model, AI agent/automation platform). Source: requirements registry index.
- % new vendor approvals with REM: Query intake tickets closed in the last 90 days; count those with a linked REM artifact. Formula: REMs on file / total new vendor approvals × 100.
- % active vendors with current-year REM: Cross-reference AI vendor inventory against REM artifact store; flag vendors with no REM dated in the current calendar year. Formula: vendors with current-year REM / total active vendors × 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 vendor requirements pack)
Evidence Location: __ Validation Date: __ Notes: ___
Q2.1: Have per-archetype requirement deltas been authored and published for all five vendor archetypes (consumer GenAI, AI-embedded SaaS, AI coding assistant, AI API/foundation-model vendor, AI agent/automation platform), and are the correct deltas automatically applied at intake based on the vendor's archetype?
Evidence Required: - [ ] Five archetype-delta documents (or pack sections) published with version numbers and tagged to TA-Vendors archetype threats - [ ] Each delta includes minimum-viable scope items specific to its archetype (e.g., no training on org code by default for AI coding assistant; explicit tool allowlist for AI agent platform; training-data posture disclosure for AI API vendor; personal-account prohibition for consumer GenAI) - [ ] Intake process routes each vendor 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-Vendors archetype threat that drove each change - [ ] Traceability matrix links delta requirements back to TA-Vendors archetype threat models and PC-Vendors priority compliance map (EU AI Act Art. 26 deployer duties, GDPR Art. 28 processor obligations) - [ ] Compensating-controls list documents approved compensating controls for common gap patterns per archetype
Outcome Metrics: | Metric | Baseline | Current | Target | Met? | Notes | |--------|----------|---------|--------|------|-------| | Base + archetype requirements packs published | 0 / 6 documents | /6 | 6 / 6 (base + 5 archetype deltas) | ☐ | Requirements registry | | % new AI vendor approvals with a completed REM | measure | % | 100% | ☐ | Intake ticket + REM artifact | | % active AI vendors in inventory with a current-year REM | measure | % | ≥90% | ☐ | Inventory × REM artifacts | | % of pack requirements tagged to a TA archetype threat and a 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: Verify all five archetype-delta documents are present in the registry with current version numbers. - % new approvals with REM: Verify REM rows for the vendor's archetype delta are populated, not only base pack rows. - % active vendors 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.
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 archetype deltas published or applied at intake)
Evidence Location: __ Validation Date: __ Notes: ___
Q3.1: Is the requirements pack wired into the vendor intake gate so that every approved AI vendor carries a completed REM, with Met rows citing specific evidence (DPA section, admin-console screenshot, SOC 2 control ID), Gap-accepted rows naming an owner and expiry date, and renewal/material-change triggers defined?
Evidence Required: - [ ] Vendor intake checklist includes a gate step requiring a completed REM before vendor approval is issued - [ ] At least three vendor REMs on file from the last 90 days, each showing Met / Gap-accepted / Not-applicable rows with specific evidence citations (DPA section, admin-console screenshot, SOC 2 control ID, vendor doc URL, demonstration note) - [ ] 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 - [ ] REM-population status per vendor is tracked and visible to the pack owner - [ ] Material-change trigger list is documented (contract renewal, vendor DPA amendment, material AI-feature change, new archetype acquired) and included in the intake checklist - [ ] Pack-version control confirms quarterly refresh cadence with at least one refresh on record
Outcome Metrics: | Metric | Baseline | Current | Target | Met? | Notes | |--------|----------|---------|--------|------|-------| | Base + archetype requirements packs published | 0 / 6 documents | /6 | 6 / 6 (base + 5 archetype deltas) | ☐ | Requirements registry | | % new AI vendor approvals with a completed REM | measure | % | 100% | ☐ | Intake ticket + REM artifact | | % active AI vendors in inventory with a current-year REM | measure | % | ≥90% | ☐ | Inventory × REM artifacts | | % of pack requirements tagged to a TA archetype threat and a 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: Confirm 6/6 documents in the registry with current version numbers. - % new approvals with REM: Pull intake ticket list for last 90 days; confirm each vendor approval was preceded by a linked REM artifact. - % active vendors with current-year REM: Run inventory × REM cross-reference; compute completion ratio. - Evidence quality check: Spot-check 10 REM rows across 3 vendor REMs; confirm each Met row cites a specific artifact. - Accepted-gap aging: Confirm median open-gap age is within ≤90 days; flag any gap without a named owner or expiry.
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 intake gate or vendor REMs on file)
Evidence Location: __ Validation Date: __ Notes: ___
Objective: Replace qualitative requirements with quantitative, SLA-bound ones; deepen per-tier requirement deltas; validate requirement-evidence continuously.
Q4.1: Do 100% of pack requirements carry a quantitative or binary evidence condition, with every SLA (incident notification hours, retention days, availability %, log-export format) and binary state (DPA clause present, no-train toggle confirmed, subprocessor list current, EU AI Act Art. 26 checklist evidence) specified, and has all qualitative "reasonable" language been removed?
Evidence Required: - [ ] Requirements pack shows no qualitative language ("reasonable," "appropriate," "sufficient") in any requirement statement; all language is measurable or binary - [ ] Incident-notification requirement specifies an SLA in hours (e.g., ≤72 hours breach notification); no "timely" or "prompt" language - [ ] No-train assertion requirement is binary: explicit no-train contract language + technical-control confirmation (admin-console setting confirmed OFF + screenshot on file) - [ ] Subprocessor-list currency requirement is binary: subprocessor list received within a defined notice period (e.g., ≤30 days before any new subprocessor is added); last notification date on file - [ ] Retention requirement specifies days: data deleted within N days of termination; last confirmation date on file - [ ] Log exportability requirement specifies format and SLA: logs exportable in SIEM-ingestible format within 5 business days of request - [ ] 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/binary condition | measure | % | 100% | ☐ | Requirements pack | | % Critical REMs re-validated 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 AI vendors with EU AI Act Art. 26 full-checklist evidence | measure | ___% | 100% | ☐ | Compliance view |
Metric Collection Guidance:
- % requirements quantitative/binary: Count requirements with a measurable SLA or explicit binary predicate vs. total requirements. Source: requirements pack document.
- % Critical REMs re-validated: Count Critical-tier vendor REMs with a re-validation run (not self-attestation alone) in the last 90 days. Formula: re-validated Critical-tier vendor REMs / total Critical-tier vendors × 100.
- Accepted-gap aging (Critical): Filter gap register to Critical-tier vendor rows; compute median calendar days open.
- % Critical vendors with Art. 26 checklist evidence: Count Critical-tier vendor REMs containing the EU AI Act Art. 26 full deployer-duty checklist with verifiable evidence (not vendor assertion alone). Formula: Critical-tier REMs with Art. 26 evidence / total Critical-tier vendors × 100.
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 (Requirements still contain qualitative language)
Evidence Location: __ Validation Date: __ Notes: ___
Q5.1: Has a per-tier pack overlay been published and enforced at intake, with Critical-tier vendors requiring red-team right, FRIA support, model-version pinning with 30-day advance notice, full Art. 26 checklist evidence, and a 60-day accepted-gap SLA, and Low-tier vendors receiving annual attestation only?
Evidence Required: - [ ] Per-tier pack overlay document published showing Critical / High / Medium / Low tier treatment matrices - [ ] Critical-tier overlay includes: red-team right (contractual right to conduct or commission a red-team exercise), FRIA support (vendor cooperates with the org's Fundamental Rights Impact Assessment), model-version pinning (vendor provides ≥30 days advance notice of model-family or major-version changes), provenance attestation, EU AI Act Art. 26 full deployer-duty checklist as a discrete REM appendix, accepted-gap aging SLA of 60 days maximum before mandatory escalation to the program sponsor - [ ] High-tier overlay includes: SOC 2 Type II + ISO 27001 annual refresh, model-version change-notification, incident-notification ≤72 hours SLA confirmed in contract - [ ] Low-tier: annual attestation refresh only; abbreviated REM process - [ ] 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 - [ ] Pack-version control shows the per-tier overlay was versioned and announced to the reviewer community
Outcome Metrics: | Metric | Baseline | Current | Target | Met? | Notes | |--------|----------|---------|--------|------|-------| | % requirements with quantitative/binary condition | measure | % | 100% | ☐ | Requirements pack | | % Critical REMs re-validated 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 AI vendors with EU AI Act Art. 26 full-checklist evidence | measure | ___% | 100% | ☐ | Compliance view |
Metric Collection Guidance: - % requirements quantitative/binary: Confirm no regressions from Q4 after the tier overlay was applied. - % Critical REMs re-validated: Verify the re-validation cadence is operating using observable-reality checks (admin-console, vendor API, IR findings, ML logs), not only vendor-provided attestation. - Accepted-gap aging (Critical): Confirm no Critical-tier vendor gap has exceeded 60 days without a documented escalation record naming the program sponsor. - % Critical vendors with Art. 26 checklist evidence: Confirm the checklist evidence is verifiable (contract language, admin-console state, or demonstrable technical controls), not vendor assertion alone.
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 per-tier overlay or tier-based intake routing)
Evidence Location: __ Validation Date: __ Notes: ___
Q6.1: Are Critical-tier vendor REMs re-validated against observed reality at least quarterly and High-tier at least semi-annually, with validation deltas routed to IM as findings, no Critical-tier accepted gap aging beyond 60 days without documented escalation, and re-validation methods using admin-console, vendor API, IR findings, and ML telemetry (not vendor attestation alone)?
Evidence Required: - [ ] REM validation log exists and shows at least one completed validation run for every Critical-tier vendor in the last 90 days, using observable reality checks (admin console, vendor API, IR findings, ML logs) - [ ] Validation method documented: select N REM rows per vendor (stratified sample), verify each cited evidence artifact against current observable reality (no-train toggle, subprocessor list currency, SOC 2 bridge letter, DPA clause, admin-console log settings, no-train probe test result) - [ ] Validation deltas (row claimed Met but evidence fails re-validation) are routed to IM as findings with severity tags and remediation SLAs matching the vendor's tier - [ ] Accepted-gaps register shows no Critical-tier vendor gap past 60 days without a documented escalation record naming the program sponsor - [ ] REM-population status per vendor reflects the last validation date and outcome for each Critical/High-tier vendor - [ ] Monthly accepted-gap aging review is documented: gaps approaching the escalation threshold trigger pre-deadline notification to the named owner - [ ] Pack-version control records any requirement amendments triggered by validation findings (e.g., a no-train assertion found disabled triggers a pack update assessment)
Outcome Metrics: | Metric | Baseline | Current | Target | Met? | Notes | |--------|----------|---------|--------|------|-------| | % requirements with quantitative/binary condition | measure | % | 100% | ☐ | Requirements pack | | % Critical REMs re-validated 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 AI vendors with EU AI Act Art. 26 full-checklist evidence | measure | ___% | 100% | ☐ | Compliance view |
Metric Collection Guidance:
- % Critical REMs re-validated: Pull REM validation log; count Critical-tier vendor REMs with a validation run recorded in the last 90 days using observable-reality checks. Formula: validated Critical-tier vendor REMs / total Critical-tier vendors × 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 backlog contains findings originating from vendor REM validation deltas in the last 90 days.
- Art. 26 checklist: Confirm the checklist evidence is current and verified against actual contract language and admin-console state, not vendor assertion.
- No-train probing: Confirm validation includes a technical probe of the no-train setting (admin-console API query or screenshot), not only a contract clause review.
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: ___
Objective: Publish the AI-vendor requirements pack as an industry-shared artifact, automate REM-evidence validation via vendor APIs and internal telemetry, and contribute to AI-vendor procurement language standards.
Q7.1: Have the AI Vendor Requirements Pack and REM schema been published under a permissive license with tracked external adoption, with the public version aligned to the internal version and ≥70% of REM evidence rows auto-validated via vendor API ingestion and internal telemetry?
Evidence Required: - [ ] AI Vendor Requirements Pack (base + 5 archetype deltas) published under a permissive license (e.g., CC BY 4.0 or Apache 2.0) with a version number and a public URL - [ ] REM schema published alongside the pack as an open artifact; schema version matches the internal REM template - [ ] External adoption tracking mechanism in place (GitHub forks, download counters, citation tracking, or equivalent); trend data available - [ ] Pack-version control aligns the public version with the internal version; no version lag exceeding one quarter - [ ] Vendor API ingestion is implemented for at least one high-signal evidence type (admin-console state, subprocessor list, SOC 2 bridge letter, or equivalent); last automated query result on file - [ ] REM-population status per vendor reflects auto-validated rows separately from manual-attestation rows - [ ] Contribution to Shared Assessments AI-vendor track, CSA AI Safety Initiative, or equivalent sector standards body is documented if a relevant working group is active
Outcome Metrics: | Metric | Baseline | Current | Target | Met? | Notes | |--------|----------|---------|--------|------|-------| | Pack adoption (forks, citations, downloads of permissively-licensed artifact) | 0 | ___ | tracked, trending up | ☐ | External telemetry | | % REM rows auto-validated | measure | % | ≥70% | ☐ | Validation telemetry | | Industry-standard contributions per year | 0 | ___ | ≥2 | ☐ | Contribution log | | Vendor redline success rate on program-contributed clauses | measure | % | ≥80% | ☐ | Contract store |
Metric Collection Guidance:
- Pack adoption: Query external telemetry (GitHub stars/forks, download counters, citation tracking) for the published pack artifact; confirm the trend is upward over a 3-month window.
- % REM rows auto-validated: Count all vendor REM rows where the last validation was performed by an automated check (vendor API query, internal ML telemetry, IR findings cross-reference) vs. total rows. Formula: auto-validated rows / total rows × 100.
- Industry-standard contributions: Count substantive contributions to recognized standards bodies in the last 12 months. Minimum 2 to meet target.
- Vendor redline success rate: Count contract negotiations in the last 12 months where a program-contributed clause was proposed; compute the percentage that were accepted (not modified or removed). Formula: accepted clauses / proposed clauses × 100. Source: contract store with clause tracking.
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 permissive-license publication or external adoption tracking)
Evidence Location: __ Validation Date: __ Notes: ___
Q8.1: Are ≥70% of vendor REM evidence rows auto-validated via vendor API ingestion and internal telemetry, with automation error-rate monitored, human review reserved for exceptions and novel clauses, and pack updates from IM findings flowing back into requirements automatically?
Evidence Required: - [ ] Vendor API ingestion is implemented for admin-console state (no-train setting), subprocessor lists (via vendor API or automated email parsing), and SOC 2 bridge letters (automated retrieval or reminder workflow) - [ ] Internal telemetry (ML-Vendors detections, IR-Vendors findings) auto-corroborates evidence claims: a detection or finding that touches a pack requirement triggers a REM row re-validation for the affected vendor - [ ] Automation error-rate (false-positive and false-negative validation results) is monitored; a defined threshold triggers human review of the affected check - [ ] Human review queue is bounded: exceptions, novel clauses (e.g., non-standard DPA language), and accepted-gap escalations are the only items requiring manual handling - [ ] Pack updates from IM findings are operationalized: every IM-Vendors incident that touches a pack requirement triggers a pack update assessment within 14 days - [ ] REM-population status per vendor reflects auto-validated rows separately from manual-attestation rows; staleness of each auto-validated row is tracked - [ ] Vendor redline success rate is tracked in the contract store and fed back to the pack owner; repeatedly-lost redlines trigger a pack update assessment
Outcome Metrics: | Metric | Baseline | Current | Target | Met? | Notes | |--------|----------|---------|--------|------|-------| | Pack adoption (forks, citations, downloads of permissively-licensed artifact) | 0 | ___ | tracked, trending up | ☐ | External telemetry | | % REM rows auto-validated | measure | % | ≥70% | ☐ | Validation telemetry | | Industry-standard contributions per year | 0 | ___ | ≥2 | ☐ | Contribution log | | Vendor redline success rate on program-contributed clauses | measure | % | ≥80% | ☐ | Contract store |
Metric Collection Guidance: - % REM rows auto-validated: Pull validation telemetry; count rows with an auto-validation result in the last 90 days vs. total active vendor REM rows. Confirm the 70% target is met. - 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 exceptions, novel clauses, and accepted-gap escalations; no standard evidence type should be pending manual review beyond the defined SLA. - Pack update SLA: Confirm IM-Vendors incidents touching pack requirements are reviewed for pack impact within 14 days; document the review outcome (pack amended, no amendment needed, or deferred with rationale). - Vendor redline success rate: Confirm the contract store has clause-level tracking; compute success rate on program-contributed clauses over 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 automated REM validation or vendor API ingestion)
Evidence Location: __ Validation Date: __ Notes: ___
Q9.1: Has the program contributed at least two substantive artifacts per year (model DPA / AI addendum clauses, REM schema, procurement language) to recognized standards bodies, with vendor redline success rate ≥80% on contributed clauses tracked in the contract store?
Evidence Required: - [ ] Contribution log lists at least 2 substantive contributions in the last 12 months with: body name (Shared Assessments, IAPP, CSA, EDPB, NIST, sector body), 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 (model DPA clause schema, REM schema for vendor requirements, or AI addendum template) 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) - [ ] Vendor redline success rate ≥80% on contributed clauses, tracked in the contract store with clause-level granularity - [ ] Pack + REM schema maintained at version parity with internal version; no lag exceeding one quarter - [ ] Contribution pipeline has ≥2 contributions in-flight at any given time
Outcome Metrics: | Metric | Baseline | Current | Target | Met? | Notes | |--------|----------|---------|--------|------|-------| | Pack adoption (forks, citations, downloads of permissively-licensed artifact) | 0 | ___ | tracked, trending up | ☐ | External telemetry | | % REM rows auto-validated | measure | % | ≥70% | ☐ | Validation telemetry | | Industry-standard contributions per year | 0 | ___ | ≥2 | ☐ | Contribution log | | Vendor redline success rate on program-contributed clauses | measure | % | ≥80% | ☐ | Contract store |
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.
- Vendor redline success rate: Count contract negotiations in the last 12 months where a program-contributed clause was proposed; compute the percentage accepted without material modification. Formula: accepted clauses / proposed clauses × 100. Source: contract store.
- Contribution pipeline health: Confirm ≥2 contributions are actively in-flight (submitted or under working-group review), not only completed.
- Pack adoption: Confirm external telemetry shows an upward trend; a flat or declining trend is a gap signal.
- L3 automation goals: Confirm vendor API ingestion and auto-validation goals from Q7 and Q8 remain met.
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 standards contributions or external publication)
Evidence Location: __ Validation Date: __ Notes: ___
| Question | Activity | Score | Notes |
|---|---|---|---|
| Q1 | L1-A: Base vendor 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: Intake gate + REM per vendor | ☐ 1.0 / ☐ 0.67 / ☐ 0.33 / ☐ 0.0 | |
| Q4 | L2-A: Quantitative requirement 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: Publish pack + REM schema | ☐ 1.0 / ☐ 0.67 / ☐ 0.33 / ☐ 0.0 | |
| Q8 | L3-B: Automated REM validation via vendor APIs | ☐ 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: Vendors Questionnaire Authored: 2026-05-15 Author: Verifhai
Instructions: