Security Requirements (SR)

Vendors Domain - HAIAMM v3.0

Practice Overview

Objective: Define the minimum, reusable security requirements pack for AI vendors that the intake gate enforces, translating the threats from TA-Vendors and the policies from PC-Vendors into specific, testable requirements the vendor must meet (or the org must compensate for) before approval.

Description: SR-Vendors authors a small, archetype-keyed AI Vendor Requirements Pack: one base requirement set that applies to every AI vendor, plus per-archetype deltas (consumer GenAI, AI-embedded SaaS, AI coding assistant, AI API/model, AI agent platform). Each requirement is stated as a testable condition with an evidence source (DPA clause, vendor docs, admin-console setting, SOC 2 control, demonstration) so the intake gate produces a decision that is defensible to auditors and customers.

Context: Without an explicit AI-vendor requirements pack, each intake invents the bar from scratch. Two reviewers score the same vendor differently, contracts miss clauses that would have been obvious, and the program cannot evidence EU AI Act deployer duties or GDPR processor adequacy across its AI vendor footprint. L1 closes that gap with the minimum viable pack, not a checklist sprawl, but the 20-ish requirements that matter for every AI vendor plus archetype-specific additions.

Maturity Level 1

Objective: Publish the AI Vendor Requirements Pack (base + per-archetype), wire it into the intake gate, and produce a requirements-evidence map for every new AI vendor

At this level, the organization stops re-deriving AI-vendor requirements intake by intake and starts selecting, adapting, and evidencing from a shared pack.

Dependencies

• TA-Vendors L1 (required): requirements derive from the archetype threat library, without threats the pack is arbitrary.
• PC-Vendors L1 (required): requirements inherit policy guardrails (AUP, Intake, Data-Sharing) and the priority compliance map.
• SM-Vendors L1 (required): inventory scope defines which vendors the pack applies to.
• Supports / unblocks: SA-Vendors L1 (architecture patterns implement the requirements), ST-Vendors L1 (tests target the requirements), IR-Vendors L1 (reviews check implementations against the requirements), DR-Vendors L1 (design reviews verify coverage).

Desired Outcomes

• A single AI Vendor Requirements Pack exists; reviewers select from it rather than drafting from scratch.
• Every approved AI vendor has a requirements-evidence map showing which pack items are met, by what evidence, and which gaps are accepted as residual risk with a named owner.
• EU AI Act deployer duties, GDPR Art. 28 processor duties, and ISO/IEC 42001 supplier controls are traceable to specific pack requirements, not hand-waved.
• The pack is versioned, owned, and refreshed quarterly as threats and compliance expectations evolve.
• Downstream practices (SA, DR, IR, ST) inherit the pack rather than re-deriving requirements.

Activities

A) Author the base AI Vendor Requirements Pack

The base pack applies to every AI vendor regardless of archetype. Keep it short (target ≤20 base requirements at L1). Each requirement has: ID, statement, rationale (threat + compliance tag), evidence source, test method, acceptance criteria.

Minimum base categories: - Data handling, no-training default, retention cap, deletion on termination, embeddings/logs retention disclosed, data residency meets org requirement. - Contracting, executed DPA / AI addendum; subprocessor list current; breach notification SLA ≤72 hours; audit or attestation right; exit data-return clause. - Identity & access, SSO/SAML or OIDC supported; admin-role separation; API-key rotation; least-privilege roles available. - Logging & observability, per-user and per-prompt/completion audit logs available to the org; export mechanism; retention ≥ org policy. - Transparency & oversight, vendor discloses model family and material changes; human-in-the-loop configuration options for decision-affecting uses; AI interaction disclosure to end users where Art. 50 applies. - Security posture, current SOC 2 Type II or ISO 27001 or equivalent; vulnerability-handling process; recent pen-test summary or bug-bounty program.

Every base requirement is tagged to: at least one TA-Vendors archetype threat, and at least one item from the PC-Vendors priority compliance map.

B) Author per-archetype requirement deltas

On top of the base pack, each archetype has a short delta (typically 3–8 additional requirements).

Deltas to ship at L1: - Consumer GenAI, enterprise plan / admin tenant required for org use; personal-account prohibition enforceable via SSO/IdP; content-filtering configuration; no memory/personalization across org boundaries unless scoped. - AI-embedded SaaS, AI feature explicitly in parent DPA or a new addendum; feature toggleable per workspace; training-on-data for the AI feature is contractually off by default; admin visibility into who uses the feature. - AI coding assistant, no training on org code by default; on-prem or no-retention execution path for regulated-data workloads; IDE/endpoint-level policy control; telemetry scoped. - AI API / foundation-model vendor, no-train contractual commitment; region pinning; model-version pinning or change-notification; rate-limit and abuse-throttling; PII-handling controls on the API layer. - AI agent / automation platform, explicit tool allowlist; per-tool scope and rate caps; human-in-the-loop gates for destructive/external actions; agent-session audit logs; defenses against indirect prompt injection (content-source provenance).

C) Wire the pack into the intake gate and produce a requirements-evidence map per vendor

Every new AI vendor approval produces a requirements-evidence map (REM): - Each applicable pack requirement marked: Met / Met-with-compensating-control / Gap-accepted / Not-applicable (with justification). - Each "Met" row cites the evidence (DPA section, admin-console screenshot, SOC 2 control ID, vendor doc URL, demonstration note). - Each "Gap-accepted" row names a compensating control, an owner, and a re-review date. - REM is stored with the intake ticket and linked from the AI vendor inventory record.

Renewal, contract change, or material AI-feature change triggers REM re-review.

Outcome Metrics (L1)

Process Metrics (leading)

• Pack review cadence, quarterly refresh recorded; changes change-logged.
• REM turnaround, median ≤3 business days from threat snapshot to REM completion.
• Reviewer consistency, calibration on sample REMs produces ≤2 row-level diffs across reviewers.

Effectiveness Metrics (business value)

• Requirements reused vs. invented, ≥80% of REM rows reference the pack unchanged; the rest are archetype adaptations.
• Audit readiness, EU AI Act deployer-duty inquiries answerable via REM evidence without re-collection.
• Downstream reuse, SA/DR/IR/ST artifacts cite REM rows directly (ingest the pack rather than redefining requirements).

Success Criteria

• Base pack plus five archetype deltas published, tagged to TA threats and the priority compliance map.
• 100% of new AI vendor approvals in the last 90 days have a REM on file.
• ≥90% of active AI vendors carry a current-year REM.
• Named pack owner and quarterly refresh cadence operating.
• Accepted-gap backlog tracked with median age inside target.

Maturity Level 2

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

At this level, requirements are testable. Every requirement either has a measurable SLA (latency, availability, incident-notification, retention, accuracy) or a binary evidence condition (DPA clause, admin-console toggle, subprocessor disclosure). Each REM (Requirements-Evidence Map) sample is validated against observed reality, attestation is not trusted without corroboration.

Dependencies

• SR-Vendors L1 (required): base + archetype requirement packs and REM.
• SM-Vendors L2 (required): tiers drive requirement depth.
• TA-Vendors L2 (required): per-vendor threats inform per-vendor requirement adjustments.
• Supports / unblocks: SA-Vendors L2, DR-Vendors L2, IR-Vendors L2 (each inherits the quantitative pack).

Desired Outcomes

• Every requirement in the pack is either measurable (with an SLA) or binary (with an evidence condition); qualitative "reasonable" language removed.
• REM rows are validated against observed reality at least quarterly for Critical/High tiers.
• Accepted-gap backlog aging is managed; no Critical-tier accepted gap over 90 days without escalation.
• Per-tier requirement pack deltas reflect measurable differentiation, not just "more" for Critical.

Activities

A) Quantitative requirement pack

• Every base requirement gets a measurable condition: incident-notification SLA in hours, retention in days, availability in %, log exportability in format, subprocessor notice in days.
• Archetype deltas similarly quantified: AI API proxy latency SLO, agent tool-scope enumeration, AI-embedded SaaS per-workspace toggle state.
• Training-data attestation requires explicit no-train contract language + technical-control confirmation.

B) Per-tier requirement depth

• Critical tier adds: red-team right, FRIA support, model-version pinning with 30-day advance notice, provenance attestation, EU AI Act Art. 26 full checklist.
• High tier: SOC 2 Type II + ISO 27001 annual refresh, model-version change-notification, incident-notification ≤72h.
• Medium: annual attestation refresh, subprocessor-list update.
• Low: annual attestation only.

C) Continuous REM-evidence validation

• Quarterly sampling for Critical; semi-annual for High, pick N REM rows, verify evidence against current reality (admin console, vendor API, IR findings, ML logs).
• Deltas raise findings routed to IM.
• Accepted-gap aging review monthly; blocker escalations to sponsor.

Outcome Metrics (L2)

Process Metrics (leading)

• Requirement-pack change-log ≥1 update/quarter.
• REM validation sampling on calendar; no missed cycles.
• Blocker-gap escalation SLA met.

Effectiveness Metrics (business value)

• Time-to-regulator-inquiry drops as REM evidence is machine-readable.
• Vendor redline patterns stabilize, recurring redline language codified into the pack.

Success Criteria

• 100% requirements quantitative or binary.
• ≥95% Critical REMs re-validated in last 90 days.
• Accepted-gap backlog inside aging target.
• Full Art. 26 evidence for 100% Critical AI vendors.

Maturity Level 3

Objective: Publish the AI-vendor requirements pack as industry-shared artifact, automate REM-evidence validation, and contribute to AI-vendor procurement language standards

At this level, the requirements pack becomes a referenced artifact outside the organization. Standards bodies adopt program-contributed clause language. REM validation is automated via vendor APIs and internal telemetry.

Dependencies

• SR-Vendors L2 (required): quantitative pack and continuous validation in place.
• PC-Vendors L3 (required): compliance-evidence automation substrate.

Desired Outcomes

• External adoption of the program's AI-vendor requirement clauses and REM schema.
• REM validation is largely automated; human time goes to novel / edge cases.
• Program contributes to AI-vendor procurement and contracting standards (Shared Assessments, CSA, sector bodies).

Activities

A) Publish the pack and REM schema

• AI-vendor requirement-pack (base + archetypes) and REM schema published as permissive-license artifacts.
• Contribute to Shared Assessments AI-vendor track (as it matures), CSA AI Safety Initiative, sector standards bodies.

B) Automated REM validation

• Vendor API ingestion for admin-console state, subprocessor lists, SOC 2 bridge letters.
• Internal telemetry (ML detections, IR findings) auto-corroborates evidence claims.
• Human review reserved for exceptions and novel clauses.

C) Standards contribution

• Contribute model DPA / AI addendum clauses to standards bodies (Shared Assessments, IAPP, CSA).
• Comment on regulatory guidance where appropriate (EDPB AI, EU AI Act deployer practice, NIST Playbook).

Outcome Metrics (L3)

Process Metrics (leading)

• Publication freshness, pack refreshed at least quarterly.
• Contribution pipeline ≥2 in-flight.
• Automation error-rate monitored; human-review backlog healthy.

Effectiveness Metrics (business value)

• Reduced time-to-contract for AI vendors (pack-compliant vendors close faster).
• Industry recognition as a contributor to AI-vendor procurement language.

Success Criteria

• Pack + REM schema published under permissive license with tracked adoption.
• ≥70% REM auto-validation.
• ≥2 industry-standard contributions per year.
• Vendor redline success rate ≥80% on contributed clauses.

Key Success Indicators

Level 1: - Base AI Vendor Requirements Pack (≤20 base requirements) plus five archetype deltas published, versioned, and tagged to TA-Vendors threats and PC-Vendors priority compliance items, reviewers select from the pack rather than drafting from scratch. - 100% of new AI vendor approvals in the last 90 days have a completed Requirements-Evidence Map (REM) on file, with every "Gap-accepted" row naming a compensating control, an owner, and a re-review date. - ≥90% of active AI vendors in the inventory carry a current-year REM; accepted-gap backlog median age inside ≤90 days. - EU AI Act deployer duties, GDPR Art. 28 processor obligations, and ISO/IEC 42001 supplier controls are traceable to specific pack requirements in every REM, not hand-waved in narrative. - Named pack owner and quarterly refresh cadence operating; downstream practices (SA, DR, IR, ST) citing REM rows rather than re-deriving requirements.

Level 2: - 100% of pack requirements carry a quantitative or binary evidence condition; all qualitative "reasonable" language removed. - ≥95% of Critical-tier REMs re-validated against observed reality in the last 90 days (admin-console, vendor API, IR findings, ML logs); deltas route to IM. - No Critical-tier accepted gap aging beyond 90 days without documented escalation to the program sponsor. - 100% of Critical AI vendors carry full EU AI Act Art. 26 checklist evidence in their REM.

Level 3: - AI Vendor Requirements Pack and REM schema published under a permissive license with tracked adoption (forks, citations, downloads trending up). - ≥70% of REM evidence rows auto-validated via vendor API ingestion and internal telemetry; human review reserved for exceptions and novel clauses. - ≥2 industry-standard contributions per year (model DPA/AI addendum clauses, REM schema) to recognized bodies (Shared Assessments, IAPP, CSA); vendor redline success rate ≥80% on contributed clauses.

Common Pitfalls

Level 1: - ❌ The base pack is authored with 40+ requirements at L1, reviewers can't complete a REM in ≤3 business days and begin skipping rows, producing REMs that are structurally complete but evidentially hollow. - ❌ Per-archetype deltas are written but never wired into the intake gate, every reviewer applies the base pack only, and agent-platform and AI coding-assistant specific requirements are missed on every intake. - ❌ "Gap-accepted" rows lack expiry dates and owners, the accepted-gap backlog grows silently until an audit surfaces a Critical-tier gap that has been "accepted" for 18 months. - ❌ Pack requirements are tagged to compliance frameworks on paper but never tested at evidence-review time, REM rows reference "GDPR Art. 28" but cite no actual DPA clause or admin-console evidence. - ❌ Downstream practices (SA, DR, IR, ST) ignore the REM and re-derive requirements independently, the pack exists but provides no actual reuse across the program. - ❌ The pack is authored once and never refreshed, quarterly cadence is declared but nobody owns the calendar item, so the pack drifts from current TA threats within two quarters.

Level 2: - ❌ Quantitative conditions are set too loosely to be meaningful ("breach notification within a reasonable time" becomes "within 72h" on paper but is never actually tested against vendor SLA terms). - ❌ REM re-validation is scheduled quarterly for Critical-tier but samples only vendor-provided attestation, admin-console state, IR findings, and ML telemetry are never cross-referenced, leaving evidence integrity unverified. - ❌ Critical-tier accepted-gap escalation process exists in policy but no escalation has ever reached the sponsor, the threshold is written but the social mechanism to invoke it is missing. - ❌ EU AI Act Art. 26 full checklist is added to Critical-tier REMs but vendors provide no supporting evidence, the checklist box is ticked with "vendor asserts compliance" and the field is not revisited. - ❌ Per-tier differentiation is documented in the pack but not enforced at intake, Low-tier vendors receive the same review depth as Critical-tier because the routing logic was never built.

Level 3: - ❌ The pack is published under a permissive license but the org stops maintaining it, the public version becomes stale while the internal version evolves, and external adopters are building on outdated requirements. - ❌ Automated REM validation covers admin-console state but not vendor-side subprocessor lists or SOC 2 bridge letters, the 30% requiring human review actually holds the highest-value evidence. - ❌ Standards contributions are submitted to bodies that have no active AI-vendor working group, contributions appear in a log but have no path to adoption and no vendor redline impact. - ❌ Vendor redline success rate is tracked per clause negotiation but not fed back to update the pack, repeatedly-lost redlines stay in the pack, creating false confidence that the program's bar is achievable.

Practice Maturity Questions

Level 1: 1. Is there a published, versioned AI Vendor Requirements Pack containing a base set (≤20 requirements) plus five per-archetype deltas, with every requirement tagged to at least one TA-Vendors archetype threat and one PC-Vendors priority-compliance item, and are reviewers selecting from the pack rather than drafting requirements per intake? 2. Do 100% of new AI vendor approvals in the last 90 days have a completed REM on file, with every applicable requirement marked Met / Met-with-compensating-control / Gap-accepted / Not-applicable, each "Met" row citing specific evidence (DPA section, admin-console screenshot, SOC 2 control ID), and each "Gap-accepted" row naming a compensating control, owner, and re-review date? 3. Is the pack on a quarterly refresh cadence with a named owner, and are downstream practices (SA, DR, IR, ST) citing REM rows rather than independently re-deriving requirements from scratch?

Level 2: 1. Do 100% of pack requirements carry a quantitative or binary evidence condition, with every SLA (incident notification hours, retention days, availability %) and binary state (DPA clause present, no-train toggle confirmed, subprocessor list current) specified, and has all qualitative "reasonable" language been removed from the pack? 2. Are ≥95% of Critical-tier REMs re-validated against observed reality (admin-console, vendor API, IR findings, ML logs) in the last 90 days, with deltas routed to IM and no Critical-tier accepted gap aging beyond 90 days without documented escalation to the program sponsor? 3. Do 100% of Critical AI vendors carry full EU AI Act Art. 26 checklist evidence in their REM, not vendor assertion alone but verified against actual contract language, admin-console state, or demonstrable technical controls?

Level 3: 1. Are the AI Vendor Requirements Pack and REM schema published under a permissive license with tracked adoption metrics (forks, citations, downloads) trending upward, and is the published version aligned with the internal version currently in use? 2. Are ≥70% of REM evidence rows auto-validated via vendor API ingestion and internal telemetry (ML detections, IR findings), with automation error-rate monitored and the human-review backlog healthy? 3. Has the program contributed ≥2 substantive artifacts per year (model DPA/AI addendum clauses, REM schema, procurement language) to recognized standards bodies (Shared Assessments, IAPP, CSA), with vendor redline success rate ≥80% on contributed clauses tracked in the contract store?

Document Version: HAIAMM v3.0 Practice: Security Requirements (SR) Domain: Vendors Last Updated: 2026-05-12 Author: Verifhai