Security Requirements (SR)

Processes Domain - HAIAMM v3.5

Generated from the canonical cell records in cells/. Do not edit by hand; edit cells/SR-Processes-L*.cell.json and re-run tools/render.py.

---

Practice Overview

Business Function: Building

Objective: Publish a base security requirements pack per processes archetype, every requirement carrying a testable acceptance criterion, so teams inherit requirements rather than negotiating them.

Description: A program at this level has written down what each processes archetype must do, once, in a form a test can check. The pack covers decision pipeline, customer-facing flow, human-in-the-loop chain, back-office augmentation, approval and review workflow, content-generation workflow and knowledge-management workflow, and every requirement carries an acceptance criterion specific enough that two reviewers assessing the same asset reach the same verdict. This is the practice that converts threat-model output into something buildable: a threat without a requirement is an observation, and a requirement without a testable criterion is an aspiration. Requirements trace back to the threats they mitigate and forward to the tests that verify them.

---

Maturity Level 1, Foundational

Objective: Publish a base security requirements pack per processes archetype, every requirement carrying a testable acceptance criterion, so teams inherit requirements rather than negotiating them.

A program at this level has written down what each processes archetype must do, once, in a form a test can check. The pack covers decision pipeline, customer-facing flow, human-in-the-loop chain, back-office augmentation, approval and review workflow, content-generation workflow and knowledge-management workflow, and every requirement carries an acceptance criterion specific enough that two reviewers assessing the same asset reach the same verdict. This is the practice that converts threat-model output into something buildable: a threat without a requirement is an observation, and a requirement without a testable criterion is an aspiration. Requirements trace back to the threats they mitigate and forward to the tests that verify them.

Dependencies

• Required: SM-Processes-L1, PC-Processes-L1, TA-Processes-L1
• Alignment (not blocking): Existing non-functional requirements and architecture standards, so AI requirements join an established intake rather than arriving separately
• Supports / unblocks: SA-Processes-L1; DR-Processes-L1; IR-Processes-L1; ST-Processes-L1; EH-Processes-L1; Required by: SR-Processes-L2

Desired Outcomes

• Every processes archetype has a base requirements pack a team can adopt rather than author.
• Every requirement carries an acceptance criterion specific enough that two reviewers reach the same verdict.
• Requirements trace backward to the threats they mitigate and forward to the tests that verify them.
• A consumption budget and its behaviour at the cap are stated as requirements rather than left to operations.
• Teams know at design time what they will be held to, rather than discovering it at review.

Activities

A) Author the base requirements pack per archetype

Write one base pack per archetype covering decision pipeline, customer-facing flow, human-in-the-loop chain, back-office augmentation, approval and review workflow, content-generation workflow and knowledge-management workflow. The pack states what any asset of that archetype must do, drawn from the TA threat library so that every requirement answers a specific threat rather than a general anxiety. In this domain the base requirements centre on a named reviewer with stated authority to refuse, a numeric information and time budget per decision, disclosure that a person is interacting with AI, a contestability and appeal route, an exercised fallback for AI unavailability, and a decision record sufficient to reconstruct the basis. Keep the base pack deliberately small, targeting fifteen to twenty-five requirements: a pack of two hundred requirements is negotiated down in practice, and the negotiation happens invisibly at the team's discretion rather than visibly at the programme's. Write each requirement as an obligation on the system rather than on the team, because a requirement phrased as an activity is satisfied by doing the activity badly. Version the packs and publish the change history so teams can see what changed and when.

B) Attach a testable acceptance criterion to every requirement

Give every requirement an acceptance criterion that states how conformance is demonstrated and by what evidence. The criterion must be specific enough that two reviewers assessing the same asset independently reach the same verdict, which is the operational test of whether a criterion is real. Prefer criteria a test can evaluate over criteria a person must judge, and where judgment is unavoidable, state the evidence the judgment rests on. Requirements that cannot be given a testable criterion are either too vague to be useful or belong in guidance rather than requirements, and moving them is better than leaving them to be argued about at every review. Map each criterion to the practice that will verify it, being implementation review, security testing or environment hardening, so that the verification path exists before the requirement is issued.

C) Establish traceability and declare the consumption envelope

Build a requirements evidence map linking each requirement backward to the TA threat it mitigates and forward to the test case, review check or detection that verifies it. Publish the map and treat a requirement with no verifying mechanism as an open gap, because an unverified requirement is a statement of intent that the programme has no way to know is met. Separately, require every archetype to declare a consumption envelope: a spend or volume cap appropriate to its expected workload, and an explicit behaviour when that cap is reached, being degrade, queue or refuse, and never silently continue. Stating the cap as a requirement rather than an operational setting is what makes it testable at per business transaction completed and reviewable at design time, and it is the point at which unbounded consumption stops being an operational surprise and becomes a design decision.

Outcome Metrics (L1)

Metric	Baseline	L1 Target	Source
Processes archetypes with a published base requirements pack	first pack authoring round	100% of inventoried archetypes within 9 months	Requirements pack register joined to the asset inventory
Requirements carrying an acceptance criterion a test or review can evaluate	first criterion pass	100% of base pack requirements	Requirements pack audit
Requirements traced backward to a TA threat and forward to a verifying mechanism	first traceability pass	≥90%, with unverified requirements published as gaps	Requirements evidence map
Archetypes declaring a consumption envelope with an explicit behaviour at the cap	first envelope pass	100% of archetypes	Requirements pack consumption clause audit
Reviewer agreement on acceptance criteria in a blind double-review sample	first calibration exercise	≥85% agreement across a 20-requirement sample	Double-review calibration record

Process Metrics (leading)

• Packs versioned with a published change history, and reviewed at least annually.
• New archetypes receive a base pack within 30 days of entering the inventory.
• Double-review calibration exercise run at least semi-annually to test criterion specificity.
• Requirements with no verifying mechanism reviewed monthly with the verifying practices.

Effectiveness Metrics (business value)

• Time from design start to requirements agreed falls, because the pack is inherited rather than negotiated.
• Design review findings relating to missing requirements fall, since teams knew the obligations at design time.
• Requirement disputes at review fall as criteria become specific enough to settle themselves.

Consumption Metrics (denominated, never absolute spend)

Metric	Denominator	Economic failure it detects	Source
Archetypes whose requirements pack declares a consumption cap and an explicit behaviour at the cap	per archetype requirements pack	unbounded consumption entering production as an operational surprise, because no requirement ever obliged the system to stop, degrade or refuse at a limit	Requirements pack consumption clause audit
Declared consumption envelope per unit of work, stated per archetype	per business transaction completed	a cap set without reference to the work the asset actually delivers, which is either so loose it never binds or so tight it blocks legitimate load and gets disabled	Requirements pack envelope values joined to the consumption ledger
Consumption-cap requirements carrying a testable acceptance criterion	per consumption requirement	a cap declared in a requirement and never tested, so its behaviour at the limit is first discovered during the incident it was written to prevent	Requirements evidence map consumption entries

Level of Effort (incremental over the level below)

• Stand-up: 160 hours · Ongoing: 70 hours/quarter
• Security Architect — primary, 26 days/year
• AppSec / SecEng — regular, 16 days/year
• AI/ML Engineer — regular, 10 days/year
• Program Manager / Practice Lead — low, 6 days/year

Success Criteria

• A base requirements pack exists for every inventoried processes archetype, deliberately small at fifteen to twenty-five requirements.
• Every requirement carries an acceptance criterion specific enough that independent reviewers reach the same verdict, verified by double-review calibration at 85% or better.
• A requirements evidence map traces at least 90% of requirements backward to a threat and forward to a verifying mechanism, with gaps published.
• Every archetype declares a consumption envelope with an explicit behaviour at the cap, expressed per unit of work.
• Requirements are phrased as obligations on the system rather than activities for the team.

---

Maturity Level 2, Comprehensive

Objective: Calibrate processes requirements packs to asset tier, maintain a per-asset requirements evidence map, and make conformance demonstrable rather than asserted.

At this level requirements scale with tier. A Critical-tier asset takes the full pack plus tier-specific additions; a Low-tier asset takes a named subset, and the subset is published rather than chosen by the team under delivery pressure. Every asset carries a requirements evidence map recording, requirement by requirement, what evidences conformance and where that evidence lives. Deviations are recorded with a rationale and an expiry rather than absorbed silently, which is the difference between a requirements practice and a requirements document.

Dependencies

• Required: SR-Processes-L1, SM-Processes-L2, TA-Processes-L2
• Alignment (not blocking): Delivery planning, so requirements land at design time rather than at review
• Supports / unblocks: SA-Processes-L2; DR-Processes-L2; IR-Processes-L2; ST-Processes-L2; EH-Processes-L2; Required by: SR-Processes-L3

Desired Outcomes

• Requirements scope is derived from asset tier rather than negotiated per team under delivery pressure.
• Every Critical- and High-tier asset carries a per-asset requirements evidence map showing what evidences each requirement.
• Deviations are recorded with rationale, compensating control and expiry rather than absorbed silently.
• Consumption caps are tier-proportionate and their at-cap behaviour is verified rather than declared.
• Conformance can be demonstrated per asset without assembling it from scratch.

Activities

A) Derive requirements scope from tier

Publish the mapping from asset tier to requirements scope: which requirements are mandatory at each tier, which are recommended, and which tier-specific additions apply above the base pack. Derive the scope from the inventory tier automatically rather than letting each team select, because scope selection under delivery pressure reliably produces the minimum defensible set and does so invisibly. Add tier-specific requirements where the tier warrants them, such as an independent conformance assessment and dual approval at Critical. Where a team believes a requirement does not apply, that is a deviation and goes through the deviation process rather than through scope interpretation, which is the distinction that keeps the tier mapping meaningful rather than advisory. Tier scope in this domain keys chiefly on decision effect on people, which is a legal rather than a technical dimension and is frequently assessed by someone who is not in the room when the process is designed.

B) Maintain a per-asset requirements evidence map

For every Critical- and High-tier asset, maintain a requirements evidence map recording per requirement its status, the evidence that demonstrates conformance, where that evidence lives, its evidence grade from E0 to E3, and its last verification date. The map is maintained continuously as the asset is built rather than assembled at review, which is what makes design review cheap and audit response fast. Wire evidence collection to the systems that already hold it, being the code repository, the CI pipeline, the test registry and the configuration store, so that the map reflects reality rather than the last time someone updated it. Report the distribution of evidence grades per asset, since an asset whose conformance rests entirely on E0 assertions is in a materially different position from one resting on E2 telemetry, and a single conformance percentage conceals that difference entirely. Evidence for process requirements lives in workflow configuration and decision records, and the evidence most often missing is proof that the reviewer had the authority and the time the design assumed.

C) Govern deviations and verify consumption caps per tier

Operate a deviation process: any requirement not met is recorded with a rationale, a compensating control, a named approver whose authority scales with tier, and a mandatory expiry date. Review the deviation register monthly, report Critical-tier deviations to the sponsor, and treat a deviation past expiry as an open finding. Deviations are healthy when visible and corrosive when absorbed, and the register is what determines which. Separately, make consumption caps tier-proportionate and verify them rather than declaring them: each Critical- and High-tier asset's cap is expressed relative to per business transaction completed, and the at-cap behaviour is exercised at least annually so that what happens at the limit is known before it happens in production. Record the exercise result, because a cap whose behaviour has never been observed is a cap nobody should rely on. Cap exercises in this domain test the escalation threshold rather than a spend limit, confirming that volume above the line escalates rather than auto-approving.

Outcome Metrics (L2)

Metric	Baseline	L2 Target	Source
Assets with a requirements scope derived automatically from their tier	first tier-derivation pass	100% of Critical and High tier assets	Requirements scope derivation joined to inventory tier
Critical- and High-tier assets with a current per-asset requirements evidence map	first evidence-map pass	≥95% of Critical, ≥85% of High	Requirements evidence map register
Requirements evidence resting on E2 or better for Critical-tier assets	first evidence grading pass	≥60% of Critical-tier requirements at E2 or above	Evidence map grade distribution
Deviations carrying rationale, compensating control, tier-appropriate approver and expiry	first deviation register review	100%, with zero deviations past expiry	Deviation register
Critical- and High-tier assets whose consumption cap behaviour has been exercised in the last 12 months	first cap exercise round	100% of Critical, ≥90% of High	Cap exercise log with dates and outcomes

Process Metrics (leading)

• Requirements scope re-derived automatically whenever an asset's tier changes.
• Evidence maps updated continuously from repository, CI and configuration signals rather than at review.
• Deviation register reviewed monthly, with Critical-tier deviations reported to the sponsor.
• Consumption cap behaviour exercised on the tier cadence and the result recorded.

Effectiveness Metrics (business value)

• Design review duration falls because conformance evidence already exists rather than being assembled during review.
• Deviation volume falls as packs are refined to match what teams genuinely need.
• Evidence grade distribution improves over time, moving conformance from assertion toward telemetry.
• Requirements-related rework late in delivery falls, reported per tier.

Consumption Metrics (denominated, never absolute spend)

Metric	Denominator	Economic failure it detects	Source
Critical- and High-tier assets whose consumption cap behaviour has been exercised and recorded	per Critical or High tier asset	a declared cap whose at-limit behaviour has never been observed, which is functionally an assumption rather than a control	Cap exercise log joined to inventory tier
Declared consumption envelope against observed consumption, per tier	per business transaction completed	caps set so far above observed load that they never bind, or so close to it that legitimate work trips them and operations disables the control	Requirements envelope values compared against the consumption ledger
Deviations granted against a consumption requirement, with compensating control recorded	per active deviation	consumption controls quietly deviated away under delivery or cost pressure, leaving the asset unbounded with no visible decision	Deviation register filtered to consumption requirements

Level of Effort (incremental over the level below)

• Stand-up: 150 hours · Ongoing: 120 hours/quarter
• Security Architect — primary, 24 days/year
• AppSec / SecEng — regular, 20 days/year
• AI/ML Engineer — regular, 12 days/year
• Compliance / Audit — low, 6 days/year
• Material new tooling: Evidence map collection wired to repository, CI and configuration systems

Success Criteria

• Requirements scope is derived automatically from asset tier, and scope disagreements route through the deviation process rather than through interpretation.
• At least 95% of Critical-tier assets carry a current per-asset requirements evidence map maintained continuously rather than assembled at review.
• Evidence grades are reported per asset, with at least 60% of Critical-tier requirements resting on E2 evidence or better.
• Every deviation carries rationale, compensating control, a tier-appropriate approver and an expiry, with none past expiry.
• Every Critical-tier asset's consumption cap behaviour has been exercised within 12 months and the result recorded.

---

Maturity Level 3, Industry-Leading

Objective: Express processes requirements as executable policy evaluated continuously in the pipeline, so conformance is enforced at merge rather than assessed at review.

At this level requirements are code. Each machine-evaluable requirement is expressed as a policy check running in the pipeline, so a change that breaches a requirement fails before it merges rather than being found at review or in production. Requirements evolve from operational evidence, with incident root causes and test failures generating new requirements on a defined cadence. The packs and the policy implementations are contributed back, which is worth more than contributing the prose because a peer can run an executable requirement and cannot run a paragraph.

Dependencies

• Required: SR-Processes-L2, IR-Processes-L2, ST-Processes-L2
• Alignment (not blocking): Engineering pipeline ownership, since requirements-as-code runs in their pipeline and fails their builds
• Supports / unblocks: Every other Processes practice at L3, which inherits enforced rather than asserted requirements

Desired Outcomes

• Machine-evaluable requirements run as policy checks in the pipeline and block non-conformant change at merge.
• Requirements evolve from incident root causes, test failures and review findings rather than on an authoring calendar.
• The non-machine-evaluable requirement set is listed explicitly and shrinking, so the automation's real reach is known.
• Requirement packs and their policy implementations are contributed back in executable form.
• Conformance is a property of the pipeline rather than a periodic assessment.

Activities

A) Express requirements as executable policy in the pipeline

Convert every machine-evaluable requirement into a policy check that runs in the workflow change and release process, evaluating the change rather than the documentation. Blocking severity follows asset tier: a Critical-tier breach blocks the workflow change, a Low-tier breach warns. Agree the blocking behaviour with engineering before enabling it, because a security check that blocks the workflow change without an agreed escalation path is a check that gets disabled within a month and takes the practice's credibility with it. Publish the list of requirements that are not machine-evaluable and review it quarterly with the aim of shrinking it, since that list is the honest measure of how far enforcement actually reaches. Provide a documented break-glass path with automatic notification and mandatory post-hoc review, because emergencies happen and an unbreakable gate gets bypassed in ways nobody sees. Process requirements resist pipeline enforcement because the artifact is a workflow configuration rather than code, so the practical approach is to assert the configurable parts, being reviewer authority, time budget and auto-approval thresholds, and to list the rest explicitly.

B) Evolve requirements from operational evidence

Close the loop from operations to requirements. Feed incident root causes, security test failures, implementation review findings and monitoring detections into a quarterly requirements review, and treat any failure mode appearing three times without a covering requirement as a mandatory pack change. Publish a service level covering the interval from a recurring failure mode to a new or amended requirement, targeting 60 days including the policy implementation. Retire requirements that operational evidence shows are no longer load-bearing, because a pack that only grows becomes one teams route around; the willingness to remove requirements is what keeps the pack small enough to be respected. Record for each requirement how many times its policy check has actually fired, which distinguishes requirements that are doing work from those that are decoration. The recurring failure modes that drive new process requirements are auto-approval thresholds raised under backlog pressure and an information panel trimmed in a user-interface change, neither of which is understood as a security change by whoever makes it.

C) Contribute executable requirement packs back

Contribute at least four substantive artifacts per year, weighted toward executable form: requirement packs with their policy implementations, acceptance criteria that others can adopt directly, and conformance check libraries. Executable contributions are worth substantially more than prose in this practice, because a peer organisation can run a policy check and merely read a requirement, and the adoption difference between the two is large. Work through OWASP projects, OpenSSF AI, sector bodies and the relevant standards communities. Count only accepted or published artifacts, review each legally before release, and prefer contributing the checks that fire most often in this environment, since those are the ones carrying the most operational evidence behind them. Process requirement packs contribute well as oversight specifications with measured outcomes, which is material almost no organisation publishes and every organisation needs.

Outcome Metrics (L3)

Metric	Baseline	L3 Target	Source
Machine-evaluable requirements running as policy checks in the workflow change and release process	L2 requirement set	≥80%, with the non-evaluable remainder listed explicitly	Policy check registry joined to the requirements packs
Critical-tier requirement breaches blocked at the workflow change-approval gate rather than found later	first quarter of pipeline telemetry	≥95% of detected breaches blocked before the workflow change is approved	Pipeline policy evaluation log
Recurring failure modes reaching a new or amended requirement within the service level	first quarter of loop telemetry	≥90% within 60 days including policy implementation	Requirements change log joined to incident and test records
Break-glass bypasses carrying automatic notification and completed post-hoc review	first quarter of bypass telemetry	100% reviewed within 5 business days	Break-glass log with review completion dates
Accepted external contributions per year in executable form	0	≥4 accepted, majority executable rather than prose	Contribution log with acceptance references

Process Metrics (leading)

• Policy checks monitored for false-positive rate, with any check above threshold tuned rather than tolerated.
• Non-machine-evaluable requirement list reviewed quarterly with an explicit reduction target.
• Requirement firing counts reviewed annually, with never-firing requirements examined for retirement.
• Contribution pipeline carries at least two executable artifacts in draft or review.

Effectiveness Metrics (business value)

• Requirement breaches reaching production fall sharply, which is the outcome pipeline enforcement exists to produce.
• Design and implementation review time falls further as conformance is already established at merge.
• Pack size stays stable or falls while coverage rises, indicating retirement is happening alongside addition.
• External adoption of contributed policy checks by peer organisations.

Consumption Metrics (denominated, never absolute spend)

Metric	Denominator	Economic failure it detects	Source
Consumption-cap requirements enforced as pipeline policy rather than asserted in a document	per consumption requirement	a cap that exists in the requirements pack but nothing prevents a change from removing or widening it, so the control erodes silently through ordinary delivery	Policy check registry filtered to consumption requirements
Changes blocked at merge for breaching a declared consumption envelope	per business transaction completed	unbounded consumption entering production through routine change, which is the ordinary path by which denial-of-wallet exposure is created without anyone deciding to create it	Pipeline policy evaluation log
Consumption-cap policy checks that have never fired	per consumption policy check	caps set so loose they can never bind, which produce the appearance of a control while permitting any consumption the system is capable of	Policy check firing counts

Level of Effort (incremental over the level below)

• Stand-up: 220 hours · Ongoing: 90 hours/quarter
• Security Architect — primary, 20 days/year
• AppSec / SecEng — regular, 24 days/year
• DevOps / Platform Engineer — regular, 18 days/year
• AI/ML Engineer — low, 8 days/year
• Material new tooling: Policy-as-code engine integrated into the delivery pipeline

Success Criteria

• At least 80% of machine-evaluable requirements run as pipeline policy checks, with the non-evaluable remainder listed explicitly and shrinking.
• Critical-tier breaches are blocked at the workflow change-approval gate, with a documented break-glass path carrying automatic notification and mandatory post-hoc review within 5 business days.
• Recurring failure modes reach a new or amended requirement, including its policy implementation, within 60 days.
• Requirements are retired as well as added, with firing counts reviewed annually and never-firing requirements examined.
• At least four accepted external contributions per year, the majority in executable rather than prose form.

---

Key Success Indicators

Level 1:

• A base requirements pack exists for every inventoried processes archetype, deliberately small at fifteen to twenty-five requirements.
• Every requirement carries an acceptance criterion specific enough that independent reviewers reach the same verdict, verified by double-review calibration at 85% or better.
• A requirements evidence map traces at least 90% of requirements backward to a threat and forward to a verifying mechanism, with gaps published.
• Every archetype declares a consumption envelope with an explicit behaviour at the cap, expressed per unit of work.
• Requirements are phrased as obligations on the system rather than activities for the team.

Level 2:

• Requirements scope is derived automatically from asset tier, and scope disagreements route through the deviation process rather than through interpretation.
• At least 95% of Critical-tier assets carry a current per-asset requirements evidence map maintained continuously rather than assembled at review.
• Evidence grades are reported per asset, with at least 60% of Critical-tier requirements resting on E2 evidence or better.
• Every deviation carries rationale, compensating control, a tier-appropriate approver and an expiry, with none past expiry.
• Every Critical-tier asset's consumption cap behaviour has been exercised within 12 months and the result recorded.

Level 3:

• At least 80% of machine-evaluable requirements run as pipeline policy checks, with the non-evaluable remainder listed explicitly and shrinking.
• Critical-tier breaches are blocked at the workflow change-approval gate, with a documented break-glass path carrying automatic notification and mandatory post-hoc review within 5 business days.
• Recurring failure modes reach a new or amended requirement, including its policy implementation, within 60 days.
• Requirements are retired as well as added, with firing counts reviewed annually and never-firing requirements examined.
• At least four accepted external contributions per year, the majority in executable rather than prose form.

---

Common Pitfalls

Level 1:

• ❌ Writing packs of two hundred requirements, which get negotiated down invisibly at each team's discretion rather than visibly at the programme's.
• ❌ Phrasing requirements as activities for the team rather than obligations on the system, which are satisfied by performing the activity badly.
• ❌ Accepting acceptance criteria that two reviewers would read differently, which turns every review into a negotiation about what the requirement meant.
• ❌ Issuing requirements with no verifying mechanism, so the programme has no way to know whether they are met.
• ❌ Leaving the consumption cap to operations, which makes unbounded spend an operational surprise rather than a design decision.

Level 2:

• ❌ Letting teams select their own requirements scope, which reliably produces the minimum defensible set and does so invisibly.
• ❌ Assembling evidence maps at review time, which makes every review expensive and every audit a project.
• ❌ Reporting a single conformance percentage, which conceals whether conformance rests on assertion or on telemetry.
• ❌ Granting deviations without expiry, after which the deviation register becomes the real requirements set.
• ❌ Declaring consumption caps without ever exercising them, so their behaviour at the limit is first learned during an incident.

Level 3:

• ❌ Enabling blocking checks without an agreed escalation path, after which the checks are disabled within a month and take the practice's credibility with them.
• ❌ Automating the easy requirements and leaving the non-evaluable list unpublished, so nobody knows how far enforcement actually reaches.
• ❌ Adding requirements without ever retiring any, producing a pack large enough that teams route around it.
• ❌ Tolerating high false-positive rates on policy checks, which trains engineers to bypass rather than to fix.
• ❌ Contributing requirement prose rather than executable checks, which peers read and do not adopt.

---

Practice Maturity Questions

Level 1:

1. Does a base security requirements pack exist for every inventoried processes archetype, deliberately small, derived from the TA threat library, and phrased as obligations on the system rather than activities for the team?
2. Does every requirement carry an acceptance criterion specific enough that two reviewers independently reach the same verdict, verified by a periodic blind double-review calibration exercise at 85% agreement or better? For Processes, the assessor should be shown the decision requirements pack and its reviewer time-budget figure.
3. Does a requirements evidence map trace at least 90% of requirements backward to a threat and forward to a verifying mechanism with gaps published, and does every archetype declare a consumption envelope with an explicit, testable behaviour at the cap? In Processes, ask to see the decision requirements pack and its reviewer time-budget figure.

Level 2:

1. Is requirements scope derived automatically from the SM L2 asset tier, with disagreements routed through a deviation process rather than resolved as scope interpretation under delivery pressure? Evidence this in the Processes domain against the decision requirements pack and its reviewer time-budget figure.
2. Does every Critical- and High-tier asset carry a per-asset requirements evidence map maintained continuously from repository, CI and configuration signals, reporting an evidence grade per requirement rather than a single conformance percentage? For Processes, the assessor should be shown the decision requirements pack and its reviewer time-budget figure.
3. Do all deviations carry rationale, compensating control, tier-appropriate approver and expiry with none past expiry, and has every Critical-tier asset's consumption cap behaviour been exercised and recorded within the last 12 months? In Processes, ask to see the decision requirements pack and its reviewer time-budget figure.

Level 3:

1. Do at least 80% of machine-evaluable requirements run as pipeline policy checks with tier-proportionate blocking severity agreed with engineering, and is the non-machine-evaluable remainder listed explicitly and reviewed quarterly for reduction? Evidence this in the Processes domain against the decision requirements pack and its reviewer time-budget figure.
2. Do recurring failure modes from incidents, test failures and review findings reach a new or amended requirement including its policy implementation within 60 days, and are requirements retired as well as added based on firing counts? For Processes, the assessor should be shown the decision requirements pack and its reviewer time-budget figure.
3. Is there a documented break-glass path with automatic notification and mandatory post-hoc review within 5 business days, and does the organisation contribute at least four accepted artifacts per year, the majority executable rather than prose? In Processes, ask to see the decision requirements pack and its reviewer time-budget figure.

---

Lightweight Questions (E0 rung)

Answerable yes/no by one person in under 30 seconds, with nothing open.

Level 1:

• Is there a written security requirements list for each kind of AI processes asset?
• Could two reviewers independently agree whether a requirement is met?
• Does any AI asset have a declared limit on what it may consume?

Level 2:

• Do your riskiest AI assets carry more requirements than the rest?
• Could you show what evidences each requirement on a given asset?
• Has anyone tested what happens when an AI asset hits its spend cap?

Level 3:

• Would a change that breaks an AI security requirement fail the build?
• Do you know which of your requirements have never once been triggered?
• Have you published a requirement check others can actually run?

---

Tracking

Level 1 — Jira Epic, labels haiamm-sr-processes-l1, haiamm-building

• Done when: Every inventoried archetype carrying a base requirements pack with testable acceptance criteria and a declared consumption envelope, with traceability at or above 90%, sustained two consecutive quarters.
• Git artifacts: requirements/processes/, requirements/pack-index.json, requirements/evidence-map.json
• Git signal: evidence-map.json is regenerated from the packs and the threat library rather than maintained by hand, and pack files carry a version and change history in git.
• CI check: requirements-traceability-check

Level 2 — Jira Epic, labels haiamm-sr-processes-l2, haiamm-building

• Done when: Critical-tier evidence map coverage at or above 95% with zero expired deviations and every Critical-tier consumption cap exercised within 12 months, sustained two consecutive quarters.
• Git artifacts: requirements/asset-evidence-maps/, requirements/deviation-register.json, requirements/cap-exercise-log.json
• Git signal: Evidence maps are regenerated from repository, CI and configuration signals rather than hand-edited, and deviation-register.json is checked by CI for entries past expiry.
• CI check: deviation-expiry-check

Level 3 — Jira Epic, labels haiamm-sr-processes-l3, haiamm-building

• Done when: Machine-evaluable requirements running as pipeline policy at or above 80% with Critical-tier breaches blocked pre-merge at or above 95%, sustained across two consecutive quarters.
• Git artifacts: requirements/policy-checks/, requirements/non-evaluable.json, governance/contribution-log.json
• Git signal: Policy checks live in the delivery pipeline configuration and their evaluation results are emitted per build, and non-evaluable.json is reviewed quarterly with a commit each interval.
• CI check: requirements-policy-gate

---

Mappings

Level	HAI TTP	ATLAS	OWASP LLM 2025	Compliance
L1	EA, RA	AML.T0029, AML.T0048	LLM06, LLM09, LLM10	EU AI Act Art. 15; EU AI Act Art. 9; NIST AI RMF MAP 2.3; NIST AI RMF MANAGE 1.3; ISO/IEC 42001 8.1
L2	EA, RA	AML.T0029, AML.T0048	LLM06, LLM09, LLM10	EU AI Act Art. 15; EU AI Act Art. 9; EU AI Act Art. 26; NIST AI RMF MANAGE 1.3; ISO/IEC 42001 8.1
L3	EA, RA	AML.T0029, AML.T0048	LLM06, LLM09, LLM10	EU AI Act Art. 15; EU AI Act Art. 17; NIST AI RMF MANAGE 1.3; ISO/IEC 42001 8.1; ISO/IEC 42001 9.1

---

Document Version: HAIAMM v3.5 (generated) / Practice: Security Requirements (SR) / Domain: Processes