Security Requirements (SR)

Processes Domain - HAIAMM v3.0

Practice Overview

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

Description: SR-Processes authors a small, archetype-keyed AI/HAI Workflow Requirements Pack: one base requirement set that applies to every AI/HAI-embedded workflow, plus per-archetype deltas (decision pipeline, customer-facing flow, HITL chain, back-office augmentation, approval/review workflow, content-generation workflow, knowledge-management workflow). Each requirement is stated as a testable condition, either a measurable SLA or a binary evidence condition, not a narrative aspiration. Every workflow 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 workflow. Cross-domain linkage is explicit: a workflow REM points to the underlying Software, Data, and Infrastructure REMs for components the workflow depends on.

Context: Without a shared requirements pack, each design review, implementation review, and process audit invents the acceptance bar from scratch. Two reviewers score the same customer-facing decision pipeline differently. EU AI Act Art. 26 deployer duties, Art. 50 disclosure requirements, and GDPR Art. 22 automated-decisioning safeguards are not traceable to specific requirements in specific workflows. Human oversight design is undocumented; override audit trails are missing; affected-persons rights surfaces are untested. SR-Processes closes that gap with the minimum viable pack, not a checklist of 60 items, but the requirements that matter for every AI/HAI-embedded workflow the org operates, plus archetype-specific additions for decision pipelines, customer-facing flows, HITL chains, and content-generation workflows.

Maturity Level 1

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

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

Dependencies

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

Desired Outcomes

• A single AI/HAI Workflow Requirements Pack exists; process owners and security reviewers select from it rather than drafting from scratch at each intake.
• Every AI/HAI-embedded workflow 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, Art. 50 disclosure, Art. 14 human oversight, GDPR Art. 22 automated-decisioning safeguards, and sector-specific obligations 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; workflow REMs cross-reference the underlying Software, Data, and Infrastructure REMs for component dependencies.

Activities

A) Author the base AI/HAI Workflow Requirements Pack

The base pack applies to every AI/HAI-embedded workflow the org operates, 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-Processes + compliance tag from PC-Processes), an evidence source, a test method, and an acceptance criterion.

Minimum base categories:

• Human oversight design (EU AI Act Art. 14): explicit documentation of HITL placement in the workflow, where human review or approval gates occur, what depth of review is required at each gate (substantive vs. notification-only), who holds override authority, what the override trigger conditions are, and what happens if a reviewer is unavailable (fallback, not silent auto-approve).
• Disclosure (EU AI Act Art. 50): for any workflow delivering AI output to an external person, a documented disclosure mechanism, how and when the affected person is informed of AI involvement, what the disclosure says, and how compliance is verified.
• Decision logging: every AI-output-driven decision is logged with: what AI output drove the decision, when the decision was made, on whose data it was made, which model/version produced the output, and which human (if any) reviewed or approved it. Log retention meeting the longest applicable regulation.
• Override audit trail: every HITL override of an AI recommendation is recorded with: reviewer identity, override direction, rationale (free-text minimum; structured rationale preferred), timestamp, and the AI output that was overridden. No override goes unrecorded.
• Output-integrity SLA: a drift-detection mechanism for the workflow's AI decision distribution, baseline established at launch; an alert threshold defined (e.g., ≥5% shift in approval/rejection rate, ≥10% shift in score distribution) that triggers human review before the next production batch.
• Reviewer-capacity / SLA: maximum HITL queue depth defined; minimum reviewer-per-volume ratio documented; maximum review SLA (time from AI output to human decision) specified; a capacity-breach procedure defined (escalate, throttle volume, not auto-approve).
• Affected-persons rights surface (GDPR Arts. 15–22): for workflows that produce decisions affecting persons, a documented path for subject access requests, explanation of the decision logic, and contestation of outcomes; the path is tested at L1, not merely documented.
• DPIA / FRIA evidence: for workflows triggering GDPR Art. 35 DPIA or EU AI Act Art. 27 FRIA obligations, evidence that the assessment has been completed, is current (last completed date on file), and that the identified risks are tracked to controls.
• Fallback / kill-switch: a documented degraded-mode procedure for AI component failure, what the workflow does when the AI is unavailable, producing low-confidence output, or behaving anomalously; a halt criterion defined and tested; the kill-switch invoking a full stop rather than silent fallback to unreviewed output.
• Sector-specific overlays (where applicable): FCRA adverse-action notice (employment and credit decision pipelines); EEOC bias-audit documentation (employment decision pipelines); NYC Local Law 144 bias audit (automated employment decision tools); CO SB-21-169 (insurance decision workflows); FINRA model-risk management (financial advisory and risk-scoring workflows).

Every base requirement is tagged to: at least one TA-Processes archetype threat and at least one item from the PC-Processes 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-Processes' archetype threat models.

Deltas to ship at L1:

• Decision pipeline: Art. 22 lawful-basis requirement, if the workflow constitutes automated decision-making with legal or significant effect under GDPR Art. 22, the lawful basis (explicit consent, contract necessity, or legal obligation exception) is documented and current; Annex III FRIA requirement, if the workflow falls under EU AI Act Annex III high-risk categories, a Fundamental Rights Impact Assessment is completed and on file; class-shift monitoring requirement, a per-protected-class outcome-distribution monitor is defined and operating, with an alert threshold that triggers review before the next production run.
• Customer-facing flow: Art. 50 disclosure UX requirement, the disclosure mechanism is tested with representative users (not assumed to be visible or understood); escalation path requirement, a defined path from AI-generated response to human agent for any customer request that the AI cannot handle, refuses, or handles with low confidence; output filter requirement, a review or filter layer between AI generation and customer delivery for any factual, advisory, or consequential output.
• HITL chain: review-UI design requirement, the review interface surfaces the AI rationale and any confidence indicator available from the model; counterfactual requirement (Critical and High tier), the reviewer is shown what change to the input would have produced a different AI output; reviewer-side injection defense requirement, the review UI treats AI-generated content as untrusted and does not allow AI-generated content to trigger workflow actions.
• Back-office augmentation: scoped-tool requirement, the AI assistant's available tool list is documented and limited to tools relevant to the workflow; output-review gate requirement, a documented expectation that staff review AI output before acting on it, with periodic auditing to confirm the expectation is met; classification-aware requirement, workflows involving regulated data classes require DPO sign-off before AI augmentation is sanctioned; session-bounded requirement, AI assistant sessions are bounded (no persistent context across workflow instances without explicit design and DPO review).
• Approval/review workflow: classifier-threshold requirement, the AI classifier's decision threshold is documented, its calibration justified, and threshold changes treated as material workflow changes requiring re-review; queue-routing-by-tier requirement, the workflow routes borderline cases (near-threshold) to human reviewers rather than auto-approving; class-shift monitor requirement (same as decision pipeline delta, applied here).
• Content-generation workflow: prompt-template versioning requirement, generation prompts are version-controlled and changes are treated as material content-policy changes requiring review; output-review gate requirement, a human review step before publication, submission, or distribution of AI-generated content for any material output (customer-facing, regulatory submission, legally consequential); copyright filter requirement, a check for copyrighted or protected material in generated content before publication; brand-voice check requirement, AI-generated content is reviewed against brand standards and legal safe-harbor language requirements.
• Knowledge-management workflow: provenance requirement, every document in the retrieval corpus has a documented source, classification label, and last-verified date; injection-defense requirement, retrieved content is treated as untrusted in the prompt structure; per-role retrieval requirement, retrieval results are scoped to the querying user's access entitlements (no retrieval above the user's clearance level); freshness SLA, corpus documents older than the defined freshness threshold are flagged or excluded from retrieval.

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

Every workflow 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: process-design document element, HITL gate implementation evidence, admin-console screenshot, test result reference, DPA clause citation, DPIA/FRIA completion date and registry reference, or live-system demonstration note.
• 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 workflow and linked from the intake ticket.
• Cross-domain linkage: the workflow REM cross-references the REMs for underlying Software, Data, and Infrastructure components. A gap in a component REM that affects the workflow is surfaced in the workflow REM, not silently omitted.

Material changes (AI model swap, HITL restructuring, new data classes, scope expansion, regulatory change) trigger REM re-review before the change goes live.

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.
• Cross-domain linkage coverage, % of workflow REMs with explicit links to underlying Software/Data/Infrastructure REMs.
• Material-change trigger rate, % of production changes that trigger a REM re-review vs. changes that ship without triggering one.

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 and Art. 50 disclosure inquiries answered via REM evidence without re-collection.
• Downstream reuse, SA, DR, IR, ST artifacts cite REM rows directly rather than re-deriving requirements independently.

Success Criteria

• Base pack plus seven archetype deltas published, tagged to TA-Processes threats and the PC-Processes priority compliance map.
• 100% of new AI/HAI-embedded workflows approved in the last 90 days have a REM on file.
• ≥90% of active AI/HAI-embedded workflows 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.
• Workflow REMs cross-reference underlying Software, Data, and Infrastructure component REMs.

Maturity Level 2

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

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 workflows, 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-Processes L1 (required): base pack, archetype deltas, and REM template must be established before quantitative refinement is meaningful.
• SM-Processes L2 (required): the risk-tier rubric (decision-affecting effect, customer reach, reversibility, human-oversight depth, regulatory scope, data classes, business criticality) determines which workflows receive full per-tier treatment.
• TA-Processes L2 (required): per-workflow deep threat models inform per-workflow requirement adjustments for Critical-tier workflows.
• Supports / unblocks: SA-Processes L2, DR-Processes L2, IR-Processes L2 (each inherits the quantitative per-tier pack), ST-Processes 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, with all qualitative "reasonable" or "appropriate" language removed.
• REM rows for Critical and High-tier workflows 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; REM auto-revalidation is triggered by updates from IR and IM findings.

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:

• Decision logging retention: specify exact retention periods by workflow tier and regulation (e.g., "decision logs retained ≥24 months for EU AI Act Art. 26 deployer-duty evidence; ≥36 months for FCRA adverse-action workflows").
• Override audit trail completeness: binary, "last audit sample of 50 random override records confirmed 100% have reviewer identity, override direction, rationale, timestamp, and AI output reference, audit date on file."
• Output-integrity drift alert: "drift-detection baseline established at launch; a ≥5% shift in approval/rejection rate or a ≥10% shift in score distribution triggers a human review gate within 24 hours, last alert test date and result on file."
• Reviewer-capacity SLA: "HITL queue depth ≤[N] cases; reviewer-per-volume ratio ≥[R] reviewers per [V] cases per day; maximum review SLA ≤[T] hours, queue metrics reported daily; breach of any threshold triggers the capacity-breach procedure."
• Kill-switch test: binary, "an emergency-halt mechanism exists, is tested quarterly, halts the workflow within ≤[T] minutes, and produces a halt-record confirming no unreviewed AI output was acted upon after halt, last test date and result on file."
• Art. 22 lawful basis: binary, "lawful basis documented at §[reference] of the DPIA/FRIA, reviewed by Legal in [month/year], current, no lawful-basis review outstanding."
• DPIA/FRIA currency: binary, "DPIA/FRIA completed [date], last reviewed [date], next review scheduled [date], no DPIA/FRIA more than 24 months stale for Critical-tier workflows."

B) Per-tier requirement depth

Publish a per-tier pack overlay aligned to the SM-Processes 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); Art. 26 full deployer-duty checklist as a discrete appendix; DPIA/FRIA evidence required and current; accepted-gap aging SLA of 60 days maximum before mandatory escalation; re-validation of all Critical-tier REM evidence quarterly.
• High tier: full base pack + applicable archetype deltas; REM required; DPIA/FRIA required for Annex III triggers; 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 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 and cross-domain linkage

Critical-tier REMs re-validated quarterly; High-tier semi-annually. Validation method: select N REM rows per workflow (stratified sample), verify each cited evidence artifact against current observable reality: - Decision logging: verify log volume, retention, and exportability against stated specification. - Override audit trail: sample audit of recent overrides confirms completeness. - Kill-switch: re-run kill-switch test; verify result meets SLA. - HITL capacity: verify queue metrics against stated thresholds. - Art. 50 disclosure: test the disclosure mechanism with a representative user interaction.

REM auto-revalidation is triggered by: findings from IR-Processes (implementation drift); incidents from IM-Processes (post-incident reviews that touch a pack requirement); pack updates from TA-Processes (new threat intelligence that changes a threat the requirement addresses).

Cross-domain linkage is re-verified at the same cadence: component REM changes (Software, Data, Infrastructure) that affect workflow requirements are surfaced to the workflow REM owner within 5 business days.

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-Processes and IM-Processes feeding SR, % of IR/IM findings that trigger a REM update for the affected requirement row.

Effectiveness Metrics (business value)

• Time-to-regulator-inquiry drops as REM evidence is pre-assembled rather than collected on demand.
• Design and process review redline patterns stabilize, recurring review points codified into the pack; teams stop reinventing the same language at each process review.
• Audit pass rate on AI-process-specific controls, external auditors 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 workflow 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 workflows carry full EU AI Act Art. 26 deployer-duty checklist evidence and current DPIA/FRIA evidence in their REM.
• Per-tier pack overlay published and enforced; REM auto-revalidation triggered by IR, IM, and TA pack updates.

Maturity Level 3

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

At this level, the requirements pack and REM become machine-processable. Workflow-execution attestation confirms requirements are met at run time, not caught weeks later at the next manual review. The pack is contributed to ISO/IEC 42005 process-security guidance, OECD AI principles implementations, and sector standards bodies.

Dependencies

• SR-Processes L2 (required): quantitative pack and continuous validation must be mature before automation is trustworthy.
• PC-Processes L3 (required): compliance-evidence automation substrate is the substrate SR L3 workflow-execution attestation consumes.
• ML-Processes L2+ (required): runtime signals (decision-log volume, HITL queue depth, drift-detection outputs) are the evidence sources that REM auto-validation reads.

Desired Outcomes

• A workflow-execution event that violates a Critical-tier REM requirement is flagged in real time, compliance is monitored continuously, 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 process security requirements (ISO/IEC 42005, OECD AI, sector ISACs).

Activities

A) Machine-readable pack and workflow-execution 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.

For workflow-execution monitoring (Critical and High-tier workflows): - Automated checks run against the workflow's REM at defined intervals or on execution triggers: decision-log volume and completeness confirmed; HITL queue depth within threshold; override audit trail completeness sampled; kill-switch test result within defined age; drift-detection baseline within alert threshold. - Checks that pass write a signed attestation to the REM record. - Checks that fail for Critical-tier workflows emit an immediate alert to the workflow owner and the IM-Processes backlog; checks that fail for High-tier workflows emit a warning and route a finding to IM-Processes. - Manual-attestation rows (Art. 22 lawful-basis review, DPIA/FRIA currency, brand-voice check) are prompted for re-confirmation at the defined cadence.

B) Automated REM-evidence validation from runtime signals

Subscribe the REM validation pipeline to: - ML-Processes monitoring, decision-log completeness signal; HITL queue-depth signal; drift-detection output; reviewer-capacity signal. - IM-Processes 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 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; workflow-specific clauses outside the standard archetype deltas.

C) Standards contribution

Contribute to: - ISO/IEC 42005, machine-readable process-level AI requirement schema; REM schema as an open artifact for AI process assurance. - OECD AI Principles implementation guidance, practitioner input on process-level human oversight requirements and decision-logging standards. - Sector standards bodies (FINRA model-risk management, CFPB adverse-action requirements, FDA SaMD guidance, EEOC AI bias audit standards), submit concrete, testable AI process security requirements as candidate clause language. - NIST AI RMF Playbook successor editions, submit practitioner commentary on GOVERN and MANAGE function process-level requirement language grounded in REM experience.

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 alert 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 compliance-review overhead for compliant workflows, automated attestation replaces manual REM review cycles for the ≥70% of requirements with automated checks.
• Zero Critical-tier workflows operating with unmet REM requirements undetected, monitoring enforces what used to be a post-hoc audit.
• Industry recognition as a contributor to AI process security requirements standards.

Success Criteria

• Machine-readable pack schema published; ≥80% of Critical-tier workflow REM requirements have automated execution-time attestation.
• ≥70% of REM evidence rows auto-validated; human review reserved for exceptions.
• Zero Critical-tier workflows with failing REM checks operating undetected (monitoring 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 Workflow Requirements Pack published: base set (≤20 requirements) plus seven per-archetype deltas (decision pipeline, customer-facing flow, HITL chain, back-office augmentation, approval/review workflow, content-generation workflow, knowledge-management workflow), every requirement tagged to a TA-Processes archetype threat and a PC-Processes priority compliance item; reviewers selecting from the pack, not drafting per workflow. - 100% of new AI/HAI-embedded workflows 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-embedded workflows in the SM inventory carry a current-year REM; workflow REMs cross-reference underlying Software, Data, and Infrastructure component REMs. - EU AI Act Art. 26 deployer duties, Art. 50 disclosure, Art. 14 human oversight, GDPR Art. 22, and sector-specific obligations 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 workflow REMs re-validated against observed reality (decision log verification, HITL queue metrics, kill-switch test, Art. 50 disclosure test, override audit sample) in the last 90 days; validation deltas routed to IM-Processes. - 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 workflows carry full EU AI Act Art. 26 deployer-duty checklist evidence and current DPIA/FRIA evidence in their REM.

Level 3: - Machine-readable Requirements Pack and REM schema published under permissive license with tracked adoption; ≥80% of Critical-tier requirements have automated workflow-execution attestation. - ≥70% of REM evidence rows auto-validated via monitoring signals, ML-Processes telemetry, and IM-Processes incident feeds; human review reserved for exceptions and novel clauses. - Zero Critical-tier workflows operating with failing REM checks undetected; monitoring telemetry confirms enforcement. - ≥2 substantive standards contributions per year to ISO/IEC 42005 / OECD AI / sector standards bodies / NIST AI RMF Playbook.

Common Pitfalls

Level 1: - ❌ The base pack is authored with 40+ requirements at L1, reviewers cannot complete a workflow 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 workflow gets the base pack only; Art. 22 lawful-basis requirements and HITL design requirements are missed on every intake for decision pipelines and HITL chains. - ❌ Gap-accepted rows lack expiry dates and named owners, the backlog grows silently until an audit surfaces a Critical-tier gap accepted for 18 months with no action. - ❌ DPIA/FRIA requirement is in the pack but the evidence row is accepted with "in progress", no completion date, no registry reference, no actual assessment, and the gap never closes. - ❌ Cross-domain linkage to Software/Data/Infrastructure REMs is specified in the template but reviewers skip it; component gaps that affect the workflow are invisible until an incident surfaces them. - ❌ Override audit trail requirement is in the base pack but no one checks whether overrides are actually being recorded, the requirement is nominal and the audit trail is empty.

Level 2: - ❌ Quantitative conditions are set too loosely to be testable ("HITL review within a reasonable timeframe" becomes "≤5 business days" on paper but is never verified against actual review queue metrics); the SLA exists but is never confirmed. - ❌ REM re-validation is scheduled quarterly for Critical-tier but samples only what process owners self-report, decision-log completeness, HITL queue metrics, and ML drift signals 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 mechanism to invoke it is absent. - ❌ Art. 26 full deployer-duty checklist is added to Critical-tier REMs but accepted with "vendor asserts compliance" for the AI model component, the deployer-duty box is ticked without any technical corroboration and is not revisited on model change. - ❌ Per-tier differentiation is documented in the pack overlay but not enforced at intake, Low-tier workflows receive the same review depth as Critical-tier.

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 discover discrepancies during implementation. - ❌ Workflow-execution attestation covers launch-time checks but not drift, a kill-switch that passes at launch is disabled six weeks later with no detection; the attestation record shows "passed." - ❌ Standards contributions are submitted to working groups with no active AI process security track, they appear in the contribution log but have no path to adoption. - ❌ Automated REM validation reports pass/fail counts to the program dashboard but never feeds failures back to the pack, repeatedly failing checks 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 Workflow Requirements Pack containing a base set (≤20 requirements) plus seven per-archetype deltas, with every requirement tagged to at least one TA-Processes archetype threat and one PC-Processes priority-compliance item, and are reviewers selecting from the pack rather than drafting requirements per workflow at intake? 2. Do 100% of new AI/HAI-embedded workflows 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 do workflow REMs cross-reference the underlying Software, Data, and Infrastructure component REMs? 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 (review queue depth, kill-switch response time, drift-detection threshold, log-retention days) and binary state (Art. 22 lawful basis documented, DPIA/FRIA current, override audit trail confirmed, Art. 50 disclosure tested) specified, and has all qualitative "reasonable" and "appropriate" language been removed? 2. Are ≥95% of Critical-tier workflow REMs re-validated against observed reality (decision-log volume, HITL queue metrics, kill-switch test, Art. 50 disclosure test, override audit sample) in the last 90 days, with validation deltas routed to IM-Processes and no Critical-tier accepted gap aging beyond 60 days without documented escalation? 3. Do 100% of Critical-tier workflows carry a full EU AI Act Art. 26 deployer-duty checklist and current DPIA/FRIA evidence in their REM with verifiable evidence (not process-owner assertion alone), and is the per-tier pack overlay enforced at SM intake, with Critical-tier workflows receiving full depth and Low-tier workflows receiving base pack only?

Level 3: 1. Is the AI/HAI Workflow Requirements Pack expressed in a machine-readable schema and monitored via workflow-execution attestation, with ≥80% of Critical-tier requirements having automated checks, zero Critical-tier workflows operating with failing REM checks undetected, and the schema published under a permissive license with tracked external adoption? 2. Are ≥70% of REM evidence rows auto-validated via workflow monitoring (ML-Processes), incident feeds (IM-Processes), and SM inventory change events, with automation error-rate monitored and human review reserved for 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, process requirement clauses) to recognized standards bodies (ISO/IEC 42005, OECD AI, sector standards, NIST AI RMF Playbook), with contributions publicly documented and traceable to adoption?

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