Security Requirements (SR)

Software Domain - HAIAMM v3.0

Practice Overview

Objective: Translate the threats from TA-Software and the policies from PC-Software into a reusable Requirements Pack for AI/HAI software the organization builds, a base set plus per-archetype deltas, so every artifact entering production carries a testable Requirements-Evidence Map (REM) rather than a blank slate.

Description: SR-Software authors a small, archetype-keyed AI/HAI Software Requirements Pack: one base requirement set that applies to every artifact, plus per-archetype deltas (LLM-integrated app, agent, RAG, fine-tune/training workload, eval harness, model-serving service, classical ML). Each requirement is stated as a testable condition, either a measurable SLA or a binary evidence condition, not a narrative aspiration. Every artifact reaching SM intake carries a Requirements-Evidence Map (REM) that links each applicable pack requirement to current evidence, accepted gaps (with a named owner and expiry date), and compensating controls. Downstream practices (SA, DR, IR, ST) inherit the REM rather than re-deriving requirements per artifact.

Context: Without a shared requirements pack, each design review, implementation review, and security test invents the acceptance bar from scratch. Two reviewers score the same agent differently. Contracts miss clauses that should be table stakes. The program cannot demonstrate EU AI Act Art. 26 deployer duties or GDPR Art. 22 automated-decisioning safeguards across its AI/HAI software portfolio because there is no shared traceability from regulation to requirement to evidence artifact. SR-Software closes that gap with the minimum viable pack, not a checklist of 60 items, but the 20-ish requirements that matter for every AI/HAI artifact the org ships, plus archetype-specific additions for agents, fine-tune workloads, RAG pipelines, and model-serving services.

Maturity Level 1

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

At this level, the organization stops re-deriving requirements intake by intake and starts selecting, adapting, and evidencing from a shared pack that every practice inherits.

Dependencies

• TA-Software L1 (required): requirements derive from the archetype threat library, without the threat library the pack is arbitrary rather than threat-driven.
• PC-Software L1 (required): requirements inherit policy guardrails (AI Acceptable Use, Intake, Data-Sharing policies) and the priority compliance map (EU AI Act Art. 26/50, GDPR Art. 22/28, ISO/IEC 42001, SOC 2 CC9.2).
• SM-Software L1 (required): the SM inventory scope and archetype taxonomy define which artifacts the pack applies to and which archetype deltas are relevant.
• Supports / unblocks: SA-Software L1 (reference patterns implement the requirements), DR-Software L1 (design reviews check proposed designs against the pack), IR-Software L1 (implementation reviews verify the REM evidence is accurate), ST-Software L1 (security tests target the requirements), IM-Software L1 (findings route to the REM gap register).

Desired Outcomes

• A single AI/HAI Software Requirements Pack exists; engineering and AppSec reviewers select from it rather than drafting from scratch at each intake.
• Every AI/HAI software artifact approved for production has a REM showing which pack requirements are met (by what evidence), which gaps are accepted (with a named owner and expiry date), and which compensating controls are in place.
• EU AI Act Art. 26 deployer duties, GDPR Art. 22 automated-decisioning safeguards, and ISO/IEC 42001 AIMS controls are traceable to specific pack requirements, not hand-waved in narrative.
• The pack is versioned, owned, and refreshed quarterly as threats (TA) and compliance expectations (PC) evolve.
• Downstream practices (SA, DR, IR, ST) inherit the REM rather than re-deriving requirements independently.

Activities

A) Author the base AI/HAI Software Requirements Pack

The base pack applies to every AI/HAI software artifact the org builds, regardless of archetype. Keep it short (target ≤20 base requirements at L1). Each requirement has: an ID, a statement, a rationale (threat tag from TA-Software + compliance tag from PC-Software), an evidence source, a test method, and an acceptance criterion.

Minimum base categories:

• Identity and auth: SSO-backed human access to the system and to all administrative interfaces; service-principal model (not a shared credential) for any agent or automated process performing actions on org or customer systems; secrets vault for API keys to LLM providers, no keys in source code, CI/CD environment variables, or plaintext configuration; per-tenant data isolation for multi-tenant artifacts (one tenant's prompts, completions, and retrieval context must not be accessible to another tenant at rest or in transit).
• Data boundary: explicit declaration of which data classes may reach the model at inference (public, internal, confidential, regulated); which data classes may be used in fine-tuning or training (with the consent basis or lawful basis for regulated data); which data classes may populate RAG retrieval indexes; a no-train assertion for each LLM provider API call (confirmed in DPA or admin-console setting), with verification that the assertion holds at the API level, not only in contract text.
• Logging: prompt + completion + tool-call + admin-audit + identity events captured for every production deployment, with retention meeting the longest applicable regulation (EU AI Act Art. 26 deployer-duty evidence, GDPR Art. 32 security, ISO/IEC 42001 AIMS operational records); export mechanism available on demand; logging not bypassable by application logic.
• Permissions (agent archetype): published tool allowlist (no tool may be invoked that is not on the list); per-tool scope minimization (each tool's parameter range restricted to the minimum required for the stated use case); human-in-the-loop gate required for any tool invocation that is destructive, external-network, or customer-account-affecting; kill-switch or circuit breaker design in place and tested.
• Output integrity: where AI output gates a decision with legal or significant effect on a person (GDPR Art. 22 trigger) or falls under EU AI Act Annex III high-risk system categories, the artifact must carry an output-integrity requirement: test corpus, drift-detection schedule, and human-validation cadence defined.
• Disclosure: for customer-facing AI/HAI features, EU AI Act Art. 50 user-facing disclosure requirement met (user informed they are interacting with an AI system); deployer-duty evidence trail per Art. 26 (the org can demonstrate it has fulfilled its obligations as the entity deploying the system).
• Failure modes: documented fallback or degraded-mode behavior for vendor outage, model deprecation, and rate-limit events, no silent failure that produces misleading output or unrecorded inaction.

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

B) Author per-archetype requirement deltas

On top of the base pack, each archetype carries a short delta (typically 3–8 additional requirements) reflecting the threat-specific obligations from TA-Software's archetype threat models.

Deltas to ship at L1:

• LLM-integrated application or feature: input sanitization policy for user-supplied content before LLM call; output handling safety (AI-generated content must not be executed, rendered as trusted code, or passed to downstream systems without validation); hallucination-consequence classification (does this output gate a decision? if yes, output-integrity requirement applies).
• Autonomous AI agent: tool allowlist is the primary delta (base pack requires it; agent delta specifies minimum-viable scope for each tool, e.g., file-read tool scoped to a declared directory, no file-write without human gate); human-in-the-loop gate specification: which actions require human approval, at what confidence threshold, with what timeout-and-fallback; agent session termination condition: defined, tested, and not bypassable by injected instructions; agent memory scope: which context persists across sessions, with a data-retention obligation matching the base pack logging requirement.
• RAG / retrieval-augmented generation pipeline: retrieval-source allow-list (enumeration of all permitted corpus sources; no dynamic source addition without a change-review gate); retrieval-source provenance: every document in the corpus has a known origin, last-verified date, and trust classification; injection-defense requirement: retrieved context treated as untrusted; the system prompt explicitly instructs the model to treat retrieved content as data, not as instructions (defense in depth, not a sole control); multi-tenant retrieval isolation: per-tenant namespacing in the vector store, verified at query time.
• Fine-tuning or model-training workload: training-data provenance: every dataset used for fine-tuning has a documented origin, a documented consent basis (or equivalent lawful basis for regulated data), and a record of which data classes are present; no-train assertion for training data sourced from vendor APIs; data minimization: training data scoped to what is necessary for the stated model capability objective; model-output privacy verification: before production, a privacy evaluation (membership-inference test or equivalent) confirms that regulated data is not trivially extractable from the fine-tuned model's completions.
• Evaluation / red-team harness: data handling: evaluation data sourced from production must be handled as production data (logging, retention, access control requirements apply); findings disposition: every finding from the harness is routed to the IM-Software backlog with a severity tag; harness access control: execution rights restricted to named personnel, not open to all engineering.
• Model-serving service: model version registry: every model version in production is tracked in the SM inventory (version, deployment date, fine-tune lineage if applicable); model-swap notification: any change to the underlying model family or version triggers a re-review gate (output-integrity for decision-affecting uses); rate-limiting and abuse throttling at the serving layer.
• Classical ML model in a product surface: model-card requirement: a published model card for every production classical ML model documenting training data sources, evaluation metrics, known failure modes, and retraining schedule; drift detection: an automated drift signal (data-distribution drift or performance drift) is defined and monitored; model access control: the prediction endpoint requires authentication; raw model weights are not accessible via the prediction API.

C) Wire the pack into the SM intake gate and produce a REM per artifact

Every artifact approved for production carries a REM. Structure:

• Each applicable pack requirement (base + archetype delta) marked: Met / Met-with-compensating-control / Gap-accepted / Not-applicable (with justification for N/A).
• Each Met row cites specific evidence: code-review finding, architecture-diagram element, admin-console screenshot, test result reference, DPA clause citation, or live-system demonstration note.
• Each Met-with-compensating-control row describes the control, its coverage, and its limitations.
• Each Gap-accepted row names a compensating control (if any), a named owner, a re-review date (maximum 90 days at L1), and the residual-risk rationale accepted by the named sponsor.
• REM is stored with the SM inventory record for the artifact and linked from the intake ticket.

Material changes (model-family swap, new tool addition, new retrieval source, new data class, scope expansion) trigger REM re-review before the change ships to production.

Outcome Metrics (L1)

Process Metrics (leading)

• Pack review cadence, quarterly refresh recorded; changes change-logged.
• REM turnaround, median ≤3 business days from threat snapshot (TA) to REM completion.
• Reviewer consistency, calibration on sample REMs produces ≤2 row-level diffs across independent reviewers.
• Material-change trigger rate, % of production changes that trigger a REM re-review vs. changes that ship without triggering one (expected zero unreviewed material changes at L1).

Effectiveness Metrics (business value)

• Requirements reused vs. invented, ≥80% of REM rows reference the pack unchanged; the remainder are archetype adaptations; zero rows invented per-intake from scratch.
• Audit readiness, EU AI Act Art. 26 deployer-duty inquiries answered via REM evidence without re-collection.
• Downstream reuse, SA, DR, IR, ST artifacts cite REM rows directly (inheriting the pack) rather than re-deriving requirements independently.

Success Criteria

• Base pack plus seven archetype deltas published, tagged to TA-Software threats and the PC-Software priority compliance map.
• 100% of new AI/HAI software artifacts approved in the last 90 days have a REM on file.
• ≥90% of active AI/HAI software artifacts in the SM inventory carry a current-year REM.
• Named pack owner and quarterly refresh cadence operating.
• Accepted-gap backlog tracked; median age inside ≤90 days; every gap has a named owner and re-review date.

Maturity Level 2

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

At this level, every requirement in the pack is either measurable (with a specific SLA) or binary (with an explicit evidence condition). REM rows are validated against observed reality for Critical/High-tier artifacts, attestation is never trusted without corroboration. Accepted-gap aging is managed per tier; Critical-tier gaps escalate on a defined SLA. The pack differentiates meaningfully across tiers rather than applying the same base list universally.

Dependencies

• SR-Software L1 (required): base pack, archetype deltas, and REM template must be established before quantitative refinement is meaningful.
• SM-Software L2 (required): the risk-tier rubric determines which artifacts receive full per-tier treatment (Critical/High get quantitative SLA validation; Medium/Low get base pack); without SM L2 tiers, per-tier calibration has no substrate.
• TA-Software L2 (required): per-artifact deep threat models inform per-artifact requirement adjustments for Critical-tier artifacts (specific tool-scope quantification, specific retrieval-source provenance requirements, specific fine-tune data-class memorization risk thresholds).
• Supports / unblocks: SA-Software L2, DR-Software L2, IR-Software L2 (each inherits the quantitative per-tier pack), ST-Software L2 (tests validate pack SLAs directly).

Desired Outcomes

• Every requirement in the pack carries a specific, testable condition, a concrete SLA in hours, days, or percentage, or a binary evidence condition (toggle state confirmed, clause present in code or DPA, test result on file), with all qualitative "reasonable" or "appropriate" language removed.
• REM rows for Critical and High-tier artifacts are re-validated against observed reality at least quarterly (Critical) and semi-annually (High), not on attestation alone.
• Accepted-gap backlog aging is managed per tier: no Critical-tier gap stays open beyond 60 days without documented escalation to the program sponsor.
• Per-tier pack differentiation is visible and enforced: Critical-tier artifacts get the full pack plus executive sign-off requirement and accepted-gap aging SLA; Low-tier artifacts get the base pack only and a fast-track REM process.

Activities

A) Quantitative and binary requirement pack

For every requirement in the base pack and each archetype delta, replace qualitative language with measurable or binary conditions:

• Logging retention: specify exact retention periods by data class and regulation (e.g., "prompt/completion logs retained ≥12 months for GDPR Art. 32 compliance; admin-audit logs retained ≥24 months for EU AI Act Art. 26 evidence").
• No-train assertion: binary, "vendor API contract includes explicit no-train clause at §X.X AND admin-console setting 'Training on your data' is set to OFF as of [date], screenshot on file."
• Human-in-the-loop gate for agents: binary, "a synchronous approval gate is implemented in the agent loop for each tool in category: destructive / external-network / customer-account-affecting, verified in code review [commit ref] and in ST canary test [test ID]."
• Kill-switch: binary, "an emergency-halt mechanism exists, is tested quarterly, and is invoked in ≤5 minutes from decision to full agent stop, last test date and result on file."
• Output integrity for decision-affecting uses: "drift detection runs daily on the production evaluation corpus; a performance degradation of ≥5% from baseline triggers a human review gate before the next batch of affected decisions is processed."
• Secrets vault for API keys: binary, "no LLM provider API key appears in source code, CI/CD environment variables, container image layers, or plaintext configuration files, confirmed by last secrets-scanning run [date] with zero findings."
• Training-data provenance: "every dataset used in fine-tuning or training is listed in the artifact's REM with: source URL or internal registry ID, data-class classification, consent basis (or GDPR Art. 6 lawful basis for personal data), and a membership-inference test result showing P(recall of training data) ≤ [defined threshold] on the production model."

B) Per-tier requirement depth

Publish a per-tier pack overlay aligned to the SM L2 tier-treatment matrix:

• Critical tier: full base pack + all applicable archetype deltas; executive sign-off requirement (named sponsor sign-off on the completed REM before Sanctioned status is issued); full REM required (no rows left blank); accepted-gap aging SLA of 60 days maximum before mandatory escalation to the sponsor; EU AI Act Art. 26 full deployer-duty checklist as a discrete appendix to the REM; re-validation of all Critical-tier REM evidence quarterly.
• High tier: full base pack + applicable archetype deltas; REM required with fast-track exemptions for low-severity N/A rows; accepted-gap aging SLA of 90 days; re-validation of REM evidence semi-annually.
• Medium tier: base pack + applicable archetype deltas; REM required; accepted-gap aging SLA of 120 days; re-validation of REM evidence annually.
• Low tier: base pack only; REM required; fast-track process (abbreviated evidence citations acceptable); re-validation at annual review.

C) Continuous REM-evidence validation

Critical-tier REMs re-validated quarterly; High-tier semi-annually. Validation method: select N REM rows per artifact (stratified sample, at least one row per base category), verify each cited evidence artifact against current observable reality: - Logging: check actual log retention and exportability against stated specification. - No-train: re-confirm admin-console setting and contract clause currency. - Kill-switch: re-run kill-switch test; verify result meets SLA. - Secrets: re-run secrets scan; confirm zero findings. - Permissions: re-verify tool allowlist against deployed agent configuration.

Validation deltas (row claimed Met but evidence now fails re-validation) are routed to IM-Software as findings with severity tags and remediation SLAs matching the artifact's tier. Accepted-gap aging reviewed monthly; gaps approaching the escalation threshold notify the named owner before the deadline, not after.

Outcome Metrics (L2)

Process Metrics (leading)

• Pack change-log, ≥1 substantive update per quarter reflecting new TA threats or PC compliance updates.
• REM validation sampling calendar, no missed quarters for Critical; no missed semi-annual cycle for High.
• Accepted-gap escalation SLA met, no gap hits escalation threshold without prior notification to the named owner.
• IR-Software feeding SR, % of IR findings that trigger a REM update for the affected requirement row (expected: rising as the IR / SR feedback loop matures).

Effectiveness Metrics (business value)

• Time-to-regulator-inquiry drops as REM evidence is machine-readable and pre-assembled rather than collected on demand.
• Build partner and design review redline patterns stabilize, recurring review points codified into the pack; teams stop reinventing the same language at each design review.
• Audit pass rate on AI-specific controls, external auditors (SOC 2, ISO 42001) find REM evidence sufficient without supplemental interviews.

Success Criteria

• 100% of pack requirements carry a quantitative or binary evidence condition; all qualitative language removed.
• ≥95% of Critical-tier REMs re-validated against observed reality in the last 90 days.
• Accepted-gap backlog inside aging targets per tier; no Critical-tier gap past 60 days without documented escalation.
• 100% of Critical-tier artifacts carry full EU AI Act Art. 26 deployer-duty checklist evidence in their REM.
• Per-tier pack overlay published and enforced; SM intake routing verified.

Maturity Level 3

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

At this level, the requirements pack and REM become machine-processable. CI/CD pipelines attest that an artifact satisfies its REM at deploy time, a deploy that fails a Critical-tier REM requirement is blocked at the pipeline gate, not caught weeks later at the next manual review. The pack is published as a referenceable artifact adopted by OpenSSF AI, OWASP SAMM AI extensions, and the NIST AI RMF Playbook reference pack ecosystem.

Dependencies

• SR-Software L2 (required): quantitative pack and continuous validation must be mature before automation is trustworthy, automating a vague pack produces fast-failing gates that engineers route around.
• PC-Software L3 (required): compliance-evidence automation substrate (machine-readable attestation) is the substrate that SR L3 CI/CD gates consume.
• ML-Software L2+ (required): runtime signals (logging completeness, kill-switch test results, drift detection outputs) are the evidence sources that REM auto-validation reads.

Desired Outcomes

• A deploy to production fails the pipeline if a Critical-tier REM requirement is unmet, compliance is enforced at deploy time, not audited afterward.
• REM evidence is largely auto-validated; human review goes to novel clauses, edge-case N/A justifications, and accepted-gap escalations.
• The pack is referenced and adopted outside the organization, standards bodies cite it; peer organizations use the REM schema.
• The program contributes to the emerging vocabulary of machine-readable AI software security requirements (OpenSSF AI, OWASP SAMM AI, NIST AI RMF Playbook reference packs, ISO/IEC 27090 successor guidance).

Activities

A) Machine-readable pack and CI/CD attestation

Express the Requirements Pack (base + archetype deltas) in a structured schema (JSON or YAML) where each requirement has: an ID, a machine-readable evidence type (log-query / config-check / test-result-reference / manual-attestation), an acceptance predicate, and a tier applicability field.

At CI/CD deploy time for Critical and High-tier artifacts: - Automated checks run against the artifact's REM: logging enabled and retention policy confirmed; no-train setting confirmed via admin-console API; secrets scanner confirms zero findings; tool allowlist confirmed against deployed agent configuration; kill-switch test result within defined age; membership-inference test result within defined age for fine-tune workloads. - Checks that pass write a signed attestation to the REM record. - Checks that fail block the deploy for Critical-tier artifacts; emit a warning and auto-route a finding to IM-Software for High-tier. - Manual-attestation rows (clauses requiring human judgment) are prompted for re-confirmation at deploy time if the artifact has changed since last manual review.

B) Automated REM-evidence validation from runtime signals

Subscribe the REM validation pipeline to: - ML-Software monitoring, logging completeness signal (prompt/completion/tool-call log volume vs. expected baseline); drift detection signal (output distribution drift for decision-affecting models). - IM-Software incident records, post-incident reviews that touch a pack requirement trigger auto-flagging of the relevant REM rows for re-validation. - SM inventory change events, a tier upgrade (e.g., Medium → Critical) auto-triggers a full REM re-validation run under the new tier's requirements depth.

Human review reserved for: novel requirement types not yet in the structured schema; accepted-gap escalations; artifact-specific clauses outside the standard archetype deltas.

C) Standards contribution

Contribute to: - OpenSSF AI working group, machine-readable requirement schema for AI/HAI software security; REM schema as an open artifact. - OWASP SAMM AI extensions, practitioner input on requirement categories and evidence conditions for AI/HAI software (Building function, Security Requirements stream). - NIST AI RMF Playbook reference packs, submit practitioner commentary on MEASURE and MANAGE function requirement language grounded in REM experience. - ISO/IEC 27090 / AI security standards successor work, submit concrete, testable AI software security requirements as candidate clause language.

Target: minimum 2 substantive contributions per year; legally vetted and anonymized.

Outcome Metrics (L3)

Process Metrics (leading)

• Structured-schema coverage, % of requirements expressed in machine-readable form (target: growing toward 100% of Critical/High-tier requirements).
• Automation error-rate monitored, false-positive and false-negative gate failures tracked; threshold triggers human review of the affected check.
• Contribution pipeline ≥2 in-flight at any given time.
• Pack published version freshness, public version aligned with internal version (no version lag exceeding one quarter).

Effectiveness Metrics (business value)

• Reduced time-to-production for compliant artifacts, the CI/CD gate replaces manual REM review cycles for the ≥70% of requirements with automated checks.
• Zero Critical-tier deploys with unmet REM requirements reaching production, the pipeline enforces what used to be a post-hoc audit.
• Industry recognition as a contributor to AI software security requirements standards.

Success Criteria

• Machine-readable pack schema published; ≥80% of Critical-tier REM requirements have CI/CD attestation at deploy time.
• ≥70% of REM evidence rows auto-validated; human review reserved for exceptions.
• Zero Critical-tier artifacts deploying to production with a failing REM check (CI/CD gate enforcing).
• Pack + REM schema published under permissive license with tracked external adoption.
• ≥2 substantive industry-standard contributions per year.

Key Success Indicators

Level 1: - AI/HAI Software Requirements Pack published: base set (≤20 requirements) plus seven per-archetype deltas (LLM-integrated app, agent, RAG, fine-tune/training, eval harness, model-serving service, classical ML), every requirement tagged to a TA-Software archetype threat and a PC-Software priority compliance item; reviewers selecting from the pack, not drafting per intake. - 100% of new AI/HAI software artifacts approved in the last 90 days have a completed REM on file, every applicable requirement marked Met / Met-with-compensating-control / Gap-accepted / Not-applicable, each Met row citing specific evidence, each Gap-accepted row naming a compensating control, owner, and re-review date. - ≥90% of active AI/HAI software artifacts in the SM inventory carry a current-year REM; accepted-gap backlog median age inside ≤90 days. - EU AI Act Art. 26 deployer duties, GDPR Art. 22 automated-decisioning safeguards, and ISO/IEC 42001 AIMS controls are traceable to specific pack requirements in every REM. - Named pack owner and quarterly refresh cadence operating; SA, DR, IR, ST practices citing REM rows rather than re-deriving requirements independently.

Level 2: - 100% of pack requirements carry a quantitative or binary evidence condition; all qualitative "reasonable" and "appropriate" language removed. - ≥95% of Critical-tier REMs re-validated against observed reality (log export verification, admin-console state, secrets scan, kill-switch test, code review) in the last 90 days; validation deltas routed to IM-Software. - No Critical-tier accepted gap open beyond 60 days without documented escalation to the program sponsor; no High-tier gap beyond 90 days. - 100% of Critical-tier artifacts carry full EU AI Act Art. 26 deployer-duty checklist evidence in their REM, not vendor assertion alone.

Level 3: - Machine-readable Requirements Pack and REM schema published under permissive license with tracked adoption; ≥80% of Critical-tier requirements have CI/CD attestation at deploy time. - ≥70% of REM evidence rows auto-validated via CI/CD signals, runtime monitoring, and admin-console API; human review reserved for exceptions and novel clauses. - Zero Critical-tier artifacts deploying to production with a failing REM check; pipeline telemetry confirms enforcement. - ≥2 substantive standards contributions per year to OpenSSF AI / OWASP SAMM AI / NIST AI RMF Playbook / ISO AI security standards successor work.

Common Pitfalls

Level 1: - ❌ The base pack is authored with 40+ requirements at L1, reviewers cannot 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 process, every artifact gets the base pack only; agent tool-scope requirements and RAG retrieval-source provenance requirements are missed on every intake for those archetypes. - ❌ Gap-accepted rows lack expiry dates and named owners, the backlog grows silently until an audit surfaces a Critical-tier gap that has been "accepted" for 18 months with no action. - ❌ Pack requirements are tagged to compliance frameworks on paper but never tested at evidence-review time, REM rows reference "EU AI Act Art. 26" but cite no actual code-review finding, config state, or DPA clause; the traceability is nominal. - ❌ Downstream practices (SA, DR, IR, ST) ignore the REM and re-derive requirements independently, the pack exists but provides zero actual reuse across the program. - ❌ Material-change trigger is not defined, model-family swaps, new tool additions, and RAG corpus expansions ship to production without triggering a REM re-review; the REM drifts from the actual artifact within weeks of production landing.

Level 2: - ❌ Quantitative conditions are set too loosely to be testable ("logging retained for an appropriate period" becomes "12 months" on paper but is never confirmed against actual log retention settings); the SLA exists but is never verified. - ❌ REM re-validation is scheduled quarterly for Critical-tier but samples only what engineers self-report, admin-console state, CI/CD telemetry, IR findings, and ML monitoring outputs are never cross-referenced; evidence integrity is 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 and tooling mechanism to invoke it is absent. - ❌ EU AI Act Art. 26 full checklist is added to Critical-tier REMs but the org accepts vendor assertion without any technical corroboration, the deployer-duty box is ticked with "vendor asserts compliance" and the field is not revisited on model change. - ❌ Per-tier differentiation is documented in the pack overlay but not enforced at intake, Low-tier artifacts receive the same review depth as Critical-tier because the intake routing logic was never built.

Level 3: - ❌ The machine-readable pack schema is published but the org stops maintaining the public version, the external artifact becomes stale while the internal version evolves; external adopters are building on outdated requirements that conflict with the current internal standard. - ❌ CI/CD attestation covers deploy-time config checks but not post-deploy drift, a kill-switch that passes at deploy time is disabled six weeks later with no detection, and the pipeline shows "passed." - ❌ Standards contributions are submitted to working groups with no active AI software security track, they appear in the contribution log but have no path to adoption and no measurable industry impact. - ❌ Automated REM validation reports pass/fail counts to the program dashboard but never feeds failures back to the pack, repeatedly failing checks (requirements that cannot be met or tested) stay in the pack, generating noise and eroding trust in the gate.

Practice Maturity Questions

Level 1: 1. Is there a published, versioned AI/HAI Software Requirements Pack containing a base set (≤20 requirements) plus seven per-archetype deltas, with every requirement tagged to at least one TA-Software archetype threat and one PC-Software priority-compliance item, and are reviewers selecting from the pack rather than drafting requirements per artifact at intake? 2. Do 100% of new AI/HAI software artifacts approved 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 verifiable evidence, each Gap-accepted row naming a compensating control, owner, and re-review date, and material-change triggers defined for when the REM must be re-reviewed? 3. Is the pack on a quarterly refresh cadence with a named owner, and are SA, DR, IR, and ST practices 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 (retention days, kill-switch response time, drift-detection threshold, secrets-scan result) and binary state (no-train toggle confirmed, tool allowlist verified, EU AI Act Art. 26 clause present) specified, and has all qualitative "reasonable" and "appropriate" language been removed from the pack? 2. Are ≥95% of Critical-tier REMs re-validated against observed reality (admin-console, CI/CD, IR findings, ML monitoring) in the last 90 days, with validation deltas routed to IM-Software and no Critical-tier accepted gap aging beyond 60 days without documented escalation to the program sponsor? 3. Does 100% of Critical-tier artifacts carry a full EU AI Act Art. 26 deployer-duty checklist in their REM with verifiable evidence (not vendor assertion alone), and is the per-tier pack overlay enforced at SM intake, with Critical-tier artifacts receiving full depth and Low-tier artifacts receiving base pack only?

Level 3: 1. Is the AI/HAI Software Requirements Pack expressed in a machine-readable schema and enforced via CI/CD attestation at deploy time, with ≥80% of Critical-tier requirements having automated checks, zero Critical-tier artifacts deploying to production with a failing REM check, and the schema published under a permissive license with tracked external adoption? 2. Are ≥70% of REM evidence rows auto-validated via CI/CD signals, runtime monitoring (ML-Software), and admin-console API ingestion, with automation error-rate monitored and human review reserved for exceptions, novel clauses, and accepted-gap escalations? 3. Does the program contribute at least two substantive artifacts per year (machine-readable requirement schema, REM schema, model requirement clauses) to recognized standards bodies (OpenSSF AI, OWASP SAMM AI, NIST AI RMF Playbook, ISO AI security standards work), with contributions publicly documented and traceable to adoption?

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