> **v3.0 framing:** The canonical source-of-truth for Security Requirements (SR) in the Vendors domain is [`../practices/SR-Vendors-OnePager.md`](../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`](../HAIAMM-v3.0-Framing.md) §8.

---

# Security Requirements (SR) - Vendors Domain
## HAIAMM Assessment Questionnaire v3.0

**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)

---

## 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 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.

---

### Question 1: Author the base AI Vendor Requirements Pack

**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:** _______________

---

### Question 2: Author per-archetype requirement deltas

**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:** _______________

---

### Question 3: Wire the pack into the intake gate and produce a REM per vendor

**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:** _______________

---

## Maturity Level 2

**Objective:** Replace qualitative requirements with quantitative, SLA-bound ones; deepen per-tier requirement deltas; validate requirement-evidence continuously.

---

### Question 4: Quantitative requirement pack

**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:** _______________

---

### Question 5: Per-tier requirement depth

**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:** _______________

---

### Question 6: Continuous REM-evidence validation

**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:** _______________

---

## Maturity Level 3

**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.

---

### Question 7: Publish the pack and REM schema as permissive-license artifacts

**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:** _______________

---

### Question 8: Automated REM validation via vendor APIs and internal telemetry

**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:** _______________

---

### Question 9: Standards contribution

**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:** _______________

---

## Summary Scorecard

| 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