Security Requirements (SR) - Endpoints Domain

HAIAMM Assessment Questionnaire v3.5

Generated from cells/SR-Endpoints-L*.cell.json. Do not edit by hand. Canonical model: HAIAMM-v3.5-Framing.md · Handbook: HAIAMM-v3.5-Handbook.md.

---

Practice: Security Requirements (SR) Domain: Endpoints Business Function: Building Purpose: Publish a base security requirements pack per endpoints archetype, every requirement carrying a testable acceptance criterion, so teams inherit requirements rather than negotiating them. Scoring Model: Evidence + Outcome Metrics (see Scoring Methodology below)

---

Instructions

• Answer from current, implemented practice, not plans or aspirations.
• Each question has two components: Evidence (what you did) and Outcome Metrics (how well it worked).
• Levels are derived, never self-assigned. Record evidence and metric values; the level falls out of the scoring below.
• Silence is not a pass. A metric you cannot produce is left blank and counts as not met. Do not estimate.
• Answer progressively. Complete all Level 1 questions before Level 2.

Evidence grade

Record how each answer is known, not only what is claimed (v3.5 framing §6). A level claim is graded at its weakest field.

Grade	Meaning
E0	Asserted by a practitioner, unevidenced
E1	Asserted, with a link to a named artifact
E2	Emitted by a system as telemetry
E3	Machine-attested and independently checkable

---

Scoring Methodology

Tier	Score	Criteria
Fully Mature	1.0	Evidence complete + ≥3 outcome metrics meet targets
Implemented	0.67	Evidence complete + 2 outcome metrics meet targets
Partial	0.33	Evidence partially complete + <2 outcome metrics meet targets
Not Implemented	0.0	No substantive evidence of practice

Practice maturity level achieved = the highest level where all 3 questions score ≥ 0.67.

---

Maturity Level 1, Foundational

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

Prerequisite cells: SM-Endpoints-L1, PC-Endpoints-L1, TA-Endpoints-L1

Question L1.1: Author the base requirements pack per archetype

Q1.1: Does a base security requirements pack exist for every inventoried endpoints archetype, deliberately small, derived from the TA threat library, and phrased as obligations on the system rather than activities for the team?

Evidence Required:

• [ ] Write one base pack per archetype covering assistant or copilot on a managed endpoint, browser-based AI tool or extension, chatbot and conversational interface, multi-modal interface, AI-augmented SaaS productivity feature, mobile AI app and edge AI device
• [ ] 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 an enforced capability allowlist, device compliance prerequisites before access, data-loss prevention on input as well as egress, per-user and per-session rate and spend limits, session logging proportionate to tier, and disclosure where a user interacts with AI. 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

Evidence grade for this question: ☐ E0 ☐ E1 ☐ E2 ☐ E3

Answer:

• ☐ Fully Mature (Evidence complete + ≥3 metrics meet targets)
• ☐ Implemented (Evidence complete + 2 metrics meet targets)
• ☐ Partial (Evidence partially complete + <2 metrics meet targets)
• ☐ Not Implemented (No evidence)

Evidence Location: _________________________________

Notes: ___________________________________________

Question L1.2: Attach a testable acceptance criterion to every requirement

Q1.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 Endpoints, the assessor should be shown the endpoint requirements pack and its input data-loss-prevention criterion.

Evidence Required:

• [ ] 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

Evidence grade for this question: ☐ E0 ☐ E1 ☐ E2 ☐ E3

Answer:

• ☐ Fully Mature (Evidence complete + ≥3 metrics meet targets)
• ☐ Implemented (Evidence complete + 2 metrics meet targets)
• ☐ Partial (Evidence partially complete + <2 metrics meet targets)
• ☐ Not Implemented (No evidence)

Evidence Location: _________________________________

Notes: ___________________________________________

Question L1.3: Establish traceability and declare the consumption envelope

Q1.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 Endpoints, ask to see the endpoint requirements pack and its input data-loss-prevention criterion.

Evidence Required:

• [ ] 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 active user and reviewable at design time, and it is the point at which unbounded consumption stops being an operational surprise and becomes a design decision

Evidence grade for this question: ☐ E0 ☐ E1 ☐ E2 ☐ E3

Answer:

• ☐ Fully Mature (Evidence complete + ≥3 metrics meet targets)
• ☐ Implemented (Evidence complete + 2 metrics meet targets)
• ☐ Partial (Evidence partially complete + <2 metrics meet targets)
• ☐ Not Implemented (No evidence)

Evidence Location: _________________________________

Notes: ___________________________________________

Level 1 Outcome Metrics

Metric	Baseline	Current	Target	Met?	Notes
Endpoints archetypes with a published base requirements pack	___	___	100% of inventoried archetypes within 9 months	☐
Requirements carrying an acceptance criterion a test or review can evaluate	___	___	100% of base pack requirements	☐
Requirements traced backward to a TA threat and forward to a verifying mechanism	___	___	≥90%, with unverified requirements published as gaps	☐
Archetypes declaring a consumption envelope with an explicit behaviour at the cap	___	___	100% of archetypes	☐
Reviewer agreement on acceptance criteria in a blind double-review sample	___	___	≥85% agreement across a 20-requirement sample	☐

Where each number is read from:

• Endpoints archetypes with a published base requirements pack — Requirements pack register joined to the asset inventory
• Requirements carrying an acceptance criterion a test or review can evaluate — Requirements pack audit
• Requirements traced backward to a TA threat and forward to a verifying mechanism — Requirements evidence map
• Archetypes declaring a consumption envelope with an explicit behaviour at the cap — Requirements pack consumption clause audit
• Reviewer agreement on acceptance criteria in a blind double-review sample — Double-review calibration record

Level 1 Consumption Metrics

Absolute spend is a ledger input, never a metric. Every row is divided by a unit of business work. If AI spend is not allocated to an owning team, record this level as blocked on allocation rather than scoring it down (v3.5 framing §12).

Metric	Denominator	Current	Economic failure it detects	Met?
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	☐
Declared consumption envelope per unit of work, stated per archetype	per active user	___	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	☐
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	☐

Level 1 30-second check (E0)

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

---

Maturity Level 2, Comprehensive

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

Prerequisite cells: SR-Endpoints-L1, SM-Endpoints-L2, TA-Endpoints-L2

Question L2.1: Derive requirements scope from tier

Q2.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 Endpoints domain against the endpoint requirements pack and its input data-loss-prevention criterion.

Evidence Required:

• [ ] 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 what the capability can read rather than what it is for, since an extension with broad page access reaches every internal application the user opens

Evidence grade for this question: ☐ E0 ☐ E1 ☐ E2 ☐ E3

Answer:

• ☐ Fully Mature (Evidence complete + ≥3 metrics meet targets)
• ☐ Implemented (Evidence complete + 2 metrics meet targets)
• ☐ Partial (Evidence partially complete + <2 metrics meet targets)
• ☐ Not Implemented (No evidence)

Evidence Location: _________________________________

Notes: ___________________________________________

Question L2.2: Maintain a per-asset requirements evidence map

Q2.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 Endpoints, the assessor should be shown the endpoint requirements pack and its input data-loss-prevention criterion.

Evidence Required:

• [ ] 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 endpoint requirements sits largely in IT systems rather than security ones, so the evidence map depends on an agreed data path that should be established before the map is promised

Evidence grade for this question: ☐ E0 ☐ E1 ☐ E2 ☐ E3

Answer:

• ☐ Fully Mature (Evidence complete + ≥3 metrics meet targets)
• ☐ Implemented (Evidence complete + 2 metrics meet targets)
• ☐ Partial (Evidence partially complete + <2 metrics meet targets)
• ☐ Not Implemented (No evidence)

Evidence Location: _________________________________

Notes: ___________________________________________

Question L2.3: Govern deviations and verify consumption caps per tier

Q2.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 Endpoints, ask to see the endpoint requirements pack and its input data-loss-prevention criterion.

Evidence Required:

• [ ] 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 active user, 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 drive a user session to its per-user ceiling, which is the control a publicly reachable interface actually depends on

Evidence grade for this question: ☐ E0 ☐ E1 ☐ E2 ☐ E3

Answer:

• ☐ Fully Mature (Evidence complete + ≥3 metrics meet targets)
• ☐ Implemented (Evidence complete + 2 metrics meet targets)
• ☐ Partial (Evidence partially complete + <2 metrics meet targets)
• ☐ Not Implemented (No evidence)

Evidence Location: _________________________________

Notes: ___________________________________________

Level 2 Outcome Metrics

Metric	Baseline	Current	Target	Met?	Notes
Assets with a requirements scope derived automatically from their tier	___	___	100% of Critical and High tier assets	☐
Critical- and High-tier assets with a current per-asset requirements evidence map	___	___	≥95% of Critical, ≥85% of High	☐
Requirements evidence resting on E2 or better for Critical-tier assets	___	___	≥60% of Critical-tier requirements at E2 or above	☐
Deviations carrying rationale, compensating control, tier-appropriate approver and expiry	___	___	100%, with zero deviations past expiry	☐
Critical- and High-tier assets whose consumption cap behaviour has been exercised in the last 12 months	___	___	100% of Critical, ≥90% of High	☐

Where each number is read from:

• Assets with a requirements scope derived automatically from their tier — Requirements scope derivation joined to inventory tier
• Critical- and High-tier assets with a current per-asset requirements evidence map — Requirements evidence map register
• Requirements evidence resting on E2 or better for Critical-tier assets — Evidence map grade distribution
• Deviations carrying rationale, compensating control, tier-appropriate approver and expiry — Deviation register
• Critical- and High-tier assets whose consumption cap behaviour has been exercised in the last 12 months — Cap exercise log with dates and outcomes

Level 2 Consumption Metrics

Absolute spend is a ledger input, never a metric. Every row is divided by a unit of business work. If AI spend is not allocated to an owning team, record this level as blocked on allocation rather than scoring it down (v3.5 framing §12).

Metric	Denominator	Current	Economic failure it detects	Met?
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	☐
Declared consumption envelope against observed consumption, per tier	per active user	___	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	☐
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	☐

Level 2 30-second check (E0)

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

---

Maturity Level 3, Industry-Leading

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

Prerequisite cells: SR-Endpoints-L2, IR-Endpoints-L2, ST-Endpoints-L2

Question L3.1: Express requirements as executable policy in the pipeline

Q3.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 Endpoints domain against the endpoint requirements pack and its input data-loss-prevention criterion.

Evidence Required:

• [ ] Convert every machine-evaluable requirement into a policy check that runs in the endpoint policy release pipeline, evaluating the change rather than the documentation
• [ ] Blocking severity follows asset tier: a Critical-tier breach blocks the policy rollout, a Low-tier breach warns
• [ ] Agree the blocking behaviour with engineering before enabling it, because a security check that blocks the policy rollout 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
• [ ] Endpoint requirements express as endpoint-management and gateway policy rather than pipeline checks, since the enforcement point is the device and the broker rather than the build

Evidence grade for this question: ☐ E0 ☐ E1 ☐ E2 ☐ E3

Answer:

• ☐ Fully Mature (Evidence complete + ≥3 metrics meet targets)
• ☐ Implemented (Evidence complete + 2 metrics meet targets)
• ☐ Partial (Evidence partially complete + <2 metrics meet targets)
• ☐ Not Implemented (No evidence)

Evidence Location: _________________________________

Notes: ___________________________________________

Question L3.2: Evolve requirements from operational evidence

Q3.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 Endpoints, the assessor should be shown the endpoint requirements pack and its input data-loss-prevention criterion.

Evidence Required:

• [ ] 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 endpoint requirements are an extension permission escalated at update and an allowlist moved to audit mode to resolve a support ticket, both invisible without endpoint telemetry

Evidence grade for this question: ☐ E0 ☐ E1 ☐ E2 ☐ E3

Answer:

• ☐ Fully Mature (Evidence complete + ≥3 metrics meet targets)
• ☐ Implemented (Evidence complete + 2 metrics meet targets)
• ☐ Partial (Evidence partially complete + <2 metrics meet targets)
• ☐ Not Implemented (No evidence)

Evidence Location: _________________________________

Notes: ___________________________________________

Question L3.3: Contribute executable requirement packs back

Q3.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 Endpoints, ask to see the endpoint requirements pack and its input data-loss-prevention criterion.

Evidence Required:

• [ ] 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
• [ ] Endpoint requirement packs contribute well as extension classifications and allowlist configurations, which is shared-maintenance work no single organisation can do adequately alone

Evidence grade for this question: ☐ E0 ☐ E1 ☐ E2 ☐ E3

Answer:

• ☐ Fully Mature (Evidence complete + ≥3 metrics meet targets)
• ☐ Implemented (Evidence complete + 2 metrics meet targets)
• ☐ Partial (Evidence partially complete + <2 metrics meet targets)
• ☐ Not Implemented (No evidence)

Evidence Location: _________________________________

Notes: ___________________________________________

Level 3 Outcome Metrics

Metric	Baseline	Current	Target	Met?	Notes
Machine-evaluable requirements running as policy checks in the endpoint policy release pipeline	___	___	≥80%, with the non-evaluable remainder listed explicitly	☐
Critical-tier requirement breaches blocked at the policy release gate rather than found later	___	___	≥95% of detected breaches blocked before the policy release is promoted	☐
Recurring failure modes reaching a new or amended requirement within the service level	___	___	≥90% within 60 days including policy implementation	☐
Break-glass bypasses carrying automatic notification and completed post-hoc review	___	___	100% reviewed within 5 business days	☐
Accepted external contributions per year in executable form	___	___	≥4 accepted, majority executable rather than prose	☐

Where each number is read from:

• Machine-evaluable requirements running as policy checks in the endpoint policy release pipeline — Policy check registry joined to the requirements packs
• Critical-tier requirement breaches blocked at the policy release gate rather than found later — Pipeline policy evaluation log
• Recurring failure modes reaching a new or amended requirement within the service level — Requirements change log joined to incident and test records
• Break-glass bypasses carrying automatic notification and completed post-hoc review — Break-glass log with review completion dates
• Accepted external contributions per year in executable form — Contribution log with acceptance references

Level 3 Consumption Metrics

Absolute spend is a ledger input, never a metric. Every row is divided by a unit of business work. If AI spend is not allocated to an owning team, record this level as blocked on allocation rather than scoring it down (v3.5 framing §12).

Metric	Denominator	Current	Economic failure it detects	Met?
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	☐
Changes blocked at merge for breaching a declared consumption envelope	per active user	___	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	☐
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	☐

Level 3 30-second check (E0)

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

---

Summary Scorecard

Level	Q1	Q2	Q3	Level score	Weakest evidence grade	Achieved?
L1	___	___	___	___	___	☐
L2	___	___	___	___	___	☐
L3	___	___	___	___	___	☐

Security Requirements (SR) maturity in the Endpoints domain: ____________

---

Document Version: HAIAMM v3.5 (generated)