Security Requirements (SR) - Data Assessment

Assessment questionnaire for measuring maturity. Answer each question honestly based on current, implemented practices.

v3.0 framing: The canonical source-of-truth for Security Requirements (SR) in the Data domain is ../practices/SR-Data-OnePager.md. Outcome metrics in this questionnaire are reproduced verbatim from that one-pager. Canonical subject and through-lines: ../HAIAMM-v3.0-Framing.md §8.

Security Requirements (SR) - Data Domain

HAIAMM Assessment Questionnaire v3.0

Practice: Security Requirements (SR) Domain: Data Purpose: Assess organizational maturity in authoring and maintaining the AI/HAI Data Requirements Pack, a base set plus per-archetype deltas, and producing a Requirements-Evidence Map (REM) for every data asset that enters or is active in an AI pipeline. Scoring Model: Evidence + Outcome Metrics (see Scoring Methodology below)

Instructions

Answer each question honestly based on current, implemented practices (not plans or aspirations)
Each question has two components: Evidence (what you did) and Outcome Metrics (how well it worked)
Scoring uses 4 tiers: Fully Mature (1.0), Implemented (0.67), Partial (0.33), Not Implemented (0.0)
Answer progressively, Complete all Level 1 questions before Level 2
Level progression, Achieve ALL questions at a lower level before advancing
Baseline first, Record current metric values before setting targets

Scoring Methodology

Score	Label	Criteria
1.0	Fully Mature	Evidence complete AND ≥3 outcome metrics meet targets
0.67	Implemented	Evidence complete AND 2 outcome metrics meet targets
0.33	Partial	Evidence partially complete AND <2 metrics meet targets
0.0	Not Implemented	No evidence present

Maturity Level 1

Objective: Publish the AI/HAI Data Requirements Pack (base plus per-archetype deltas), wire it into the SM intake gate, and produce a Requirements-Evidence Map for every data asset entering an AI pipeline.

Question 1: Author the base AI/HAI Data Requirements Pack

Q1.1: Does a published, versioned AI/HAI Data Requirements Pack exist containing a base set (target ≤20 requirements) covering classification/consent-basis/lineage/retention/cross-border flows/encryption/access control/no-train assertions/DSAR, with every requirement tagged to at least one TA-Data archetype threat and one PC-Data priority-compliance item?

Evidence Required: - [ ] Base requirements pack document published in the requirements registry with a version number and a named owner - [ ] Pack covers minimum base categories: classification and labeling, consent and lawful basis, lineage and provenance, retention, cross-border flows (GDPR Arts. 44–49), encryption, access control, no-train assertions, and Data Subject Access Rights (DSAR) - [ ] Each requirement row carries: ID, statement, rationale (threat tag + compliance tag), evidence source, test method, and acceptance criterion - [ ] REM (Requirements-Evidence Map) template exists and is linked from the SM intake checklist; template includes Met / Met-with-compensating-control / Gap-accepted / Not-applicable columns with evidence citation, gap owner, gap expiry, and compensating-control description - [ ] Accepted-gaps register exists with named owner and expiry date per row - [ ] Pack-version control record shows version, change date, and change summary for each revision - [ ] Traceability matrix links each base requirement to at least one GDPR article (Arts. 6, 9, 17, 22, 28, 35, 44–49) or EU AI Act Art. 10 training-data quality requirement

Outcome Metrics: | Metric | Baseline | Current | Target | Met? | Notes | |--------|----------|---------|--------|------|-------| | Base + archetype requirements packs published | 0 / 8 documents | /8 | 8 / 8 (base + 7 archetype deltas) | ☐ | Requirements registry | | % new AI/HAI data asset approvals with a completed REM | measure | % | 100% | ☐ | SM intake ticket + REM artifact | | % active AI/HAI data assets in inventory with a current-year REM | measure | % | ≥90% | ☐ | Inventory × REM artifacts | | % of pack requirements tagged to a TA-Data archetype threat and a PC-Data priority-compliance item | measure | % | 100% | ☐ | Pack metadata | | Accepted-gap aging (median age of open accepted-gap rows) | measure | ___ days | ≤90 days | ☐ | REM backlog |

Metric Collection Guidance: - Packs published: Count published documents in the requirements registry: 1 base + 7 archetype deltas (training corpus, inference input stream, retrieval store, prompt/completion log corpus, embedding store, fine-tuning dataset, evaluation/test set). Source: requirements registry index. - % new approvals with REM: Query SM intake tickets closed in the last 90 days; count those with a linked REM artifact. Formula: REMs on file / total new data-asset approvals × 100. - % active assets with current-year REM: Cross-reference SM inventory against REM artifact store; flag assets with no REM dated in the current calendar year. Formula: assets with current-year REM / total active assets × 100. - % requirements tagged: Inspect pack metadata fields; count requirements with both a TA threat tag and a PC compliance tag. Formula: tagged requirements / total requirements × 100. - Accepted-gap aging: Query the accepted-gaps register; compute median calendar days from gap-open date to today for all currently open rows.

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 of a published data requirements pack)

Evidence Location: __ Validation Date: __ Notes: ___

Question 2: Author per-archetype requirement deltas

Q2.1: Have per-archetype requirement deltas been authored and published for all seven data archetypes (training corpus, inference input stream, retrieval store, prompt/completion log corpus, embedding store, fine-tuning dataset, evaluation/test set), and are the correct deltas automatically applied at intake?

Evidence Required: - [ ] Seven archetype-delta documents (or pack sections) published with version numbers and tagged to TA-Data archetype threats - [ ] Each delta includes minimum-viable scope items specific to its archetype (e.g., DPIA-gated curation for fine-tuning datasets, per-tenant retrieval isolation for retrieval stores, PII redaction at logging for prompt/completion log corpus) - [ ] Intake process routes each data asset to base pack + applicable archetype delta(s); routing logic is documented and tested with at least one intake example per archetype - [ ] REM template enforces that archetype-specific delta rows are present and populated for the declared archetype - [ ] Pack-version control record reflects delta amendments and cross-references the TA-Data archetype threat that drove each change - [ ] Traceability matrix links delta requirements back to TA-Data archetype threat models and PC-Data priority compliance map (GDPR Art. 35 DPIA triggers, EU AI Act Art. 10 training data requirements) - [ ] Compensating-controls list documents approved compensating controls for common gap patterns per archetype

Metric Collection Guidance: - Packs published: Same as Q1, verify all seven archetype-delta documents are present in the registry with current version numbers. - % new approvals with REM: Same as Q1, verify REM rows for the asset's archetype delta are populated, not only base pack rows. - % active assets with current-year REM: Same as Q1, confirm archetype delta rows are present in each REM. - % requirements tagged: Confirm all delta requirements carry both a TA threat tag and a PC compliance tag; flag untagged rows. - Accepted-gap aging: Include archetype-delta gap rows in the aging calculation.

Evidence Location: __ Validation Date: __ Notes: ___

Question 3: Wire the pack into the SM intake gate and produce a REM per asset

Q3.1: Is the requirements pack wired into the SM intake gate so that every AI/HAI data asset approved for use in an AI pipeline carries a completed REM, with Met rows citing specific evidence (consent record, DPA clause, DPIA reference, lineage record), Gap-accepted rows naming an owner and expiry date, and material-change triggers defined?

Evidence Required: - [ ] SM intake checklist includes a gate step requiring a completed REM before the data asset is approved for pipeline use - [ ] At least three production REMs on file from the last 90 days, each showing Met / Gap-accepted / Not-applicable rows with specific evidence citations (not narrative assertions) - [ ] Each Met row in the sample REMs cites a specific artifact: classification label in the data catalog, consent-basis record, lineage record, DPA clause citation, admin-console screenshot, DPIA reference, or audit-log sample - [ ] Each Gap-accepted row carries: compensating control description (or "none"), named owner, re-review date (≤90 days from open date at L1), and residual-risk rationale - [ ] REM-population status per asset is tracked and visible to the pack owner - [ ] Material-change trigger list is documented (new data source added, classification change, new cross-border flow, new downstream AI use) and included in the intake checklist - [ ] Pack-version control confirms quarterly refresh cadence with at least one refresh on record

Metric Collection Guidance: - Packs published: Confirm 8/8 documents in the registry with current version numbers. - % new approvals with REM: Pull SM intake ticket list for last 90 days; confirm each pipeline approval was preceded by a linked REM artifact. - % active assets with current-year REM: Run inventory × REM cross-reference; compute completion ratio. - Evidence quality check: Spot-check 10 REM rows across 3 assets; confirm each Met row cites a specific evidence artifact, not a narrative. - Accepted-gap aging: Confirm median open-gap age is within ≤90 days; flag any gap without a named owner or expiry.

Evidence Location: __ Validation Date: __ Notes: ___

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 data assets.

Question 4: Quantitative and binary requirement pack

Q4.1: Do 100% of pack requirements carry a quantitative or binary evidence condition, with every SLA (retention days, DSAR response time, key rotation interval, audit-log retention period) and binary state (no-train toggle confirmed, DPIA current, SCC mechanism documented, cross-border flow covered) specified, and has all qualitative "reasonable" and "appropriate" language been removed?

Evidence Required: - [ ] Requirements pack shows no qualitative language in any requirement statement; all language is measurable or binary - [ ] Encryption at rest requirement is binary: classification-tier-appropriate encryption confirmed; key rotation ≤365 days for Critical-tier; last rotation date on file with zero overdue keys - [ ] No-train assertion requirement is binary: vendor admin-console setting confirmed OFF + screenshot on file + quarterly re-verification cadence documented; last re-verification result on file - [ ] DSAR deletion capability requirement specifies SLA: deletion requests fulfilled within 30 calendar days (standard) / 60 days (complex training-corpus cases); last DSAR test result on file; zero requests past statutory deadline in last 12 months - [ ] Cross-border transfer mechanism requirement is binary: SCC / adequacy / BCR documented for each cross-border personal-data flow; mechanism currency re-confirmed within last 12 months; zero flows without a documented mechanism - [ ] REM template updated to reflect quantitative conditions; each row's evidence field maps to the specific SLA or binary predicate - [ ] Pack-version control log shows the quantitative update was a tracked amendment with a version bump

Outcome Metrics: | Metric | Baseline | Current | Target | Met? | Notes | |--------|----------|---------|--------|------|-------| | % requirements with quantitative or binary evidence condition | measure | % | 100% | ☐ | Requirements pack | | % Critical-tier REMs re-validated against observed reality in last 90 days | measure | % | ≥95% | ☐ | REM validation log | | Accepted-gap aging, median age of Critical-tier open gaps | measure | ___ days | ≤60 days | ☐ | Gap register | | % Critical-tier personal-data assets with a completed and current DPIA | measure | % | 100% | ☐ | Compliance view | | % SR-Software REMs cross-referencing the relevant SR-Data REM | measure | % | ≥90% for Critical/High Software artifacts | ☐ | Cross-domain traceability log |

Metric Collection Guidance: - % requirements quantitative/binary: Count requirements with a measurable SLA or explicit binary predicate vs. total requirements. Manual review or structured-schema parse of the pack document. - % Critical-tier REMs re-validated: Count Critical-tier assets whose REM validation log shows a re-validation run (not self-attestation alone) in the last 90 days. Formula: re-validated Critical-tier assets / total Critical-tier assets × 100. - Accepted-gap aging (Critical): Filter gap register to Critical-tier rows; compute median calendar days open. - % Critical-tier personal-data assets with current DPIA: Count Critical-tier personal-data assets with a DPIA completed and reviewed within the last 12 months or since last material change. Formula: assets with current DPIA / total Critical-tier personal-data assets × 100. - % SR-Software REMs cross-referencing SR-Data REM: Query the SR-Software REM store for Critical/High-tier Software artifacts; count those that include a reference to the corresponding SR-Data REM. Formula: cross-referencing Software REMs / total Critical/High Software artifacts × 100.

Evidence Location: __ Validation Date: __ Notes: ___

Question 5: Per-tier requirement depth

Q5.1: Has a per-tier pack overlay been published and enforced at SM intake, with Critical-tier personal-data assets requiring a DPIA plus executive sign-off, a 60-day accepted-gap SLA, and SR-Software cross-referencing, and Low-tier assets receiving base pack only?

Evidence Required: - [ ] Per-tier pack overlay document published showing Critical / High / Medium / Low tier treatment matrices with distinct requirement depth and gap-aging SLAs - [ ] Critical-tier overlay includes: full base pack + all applicable archetype deltas; DPIA mandatory (binary gate); DPO or Privacy Officer sign-off on the completed REM before pipeline approval; EU AI Act Art. 10 data-quality checklist; 60-day accepted-gap aging SLA; quarterly REM re-validation; SR-Software cross-reference required for every Software-domain artifact that consumes the asset - [ ] SM intake routing logic enforces tier-appropriate depth; intake ticket records tier assignment and pack overlay version applied - [ ] Accepted-gaps register is tiered: Critical-tier gaps are flagged before the 60-day escalation threshold, with pre-deadline notification to the named owner - [ ] REM-population status per asset is visible by tier, with Critical-tier completion tracked separately - [ ] Cross-domain linkage process is documented: SR-Software REMs for Critical/High Software artifacts reference the SR-Data REM for every data asset they consume; a change in data-asset classification triggers a flag on the consuming Software artifact's REM - [ ] Pack-version control shows the per-tier overlay was versioned and announced to the reviewer community

Metric Collection Guidance: - % requirements quantitative/binary: Confirm no regressions, all requirements remain quantitative/binary after the tier overlay was applied. - % Critical-tier REMs re-validated: Verify the re-validation cadence is operating, not just scheduled; confirm observable-reality checks are used. - Accepted-gap aging (Critical): Confirm no Critical-tier gap has exceeded 60 days without a documented escalation record. - % Critical-tier personal-data assets with current DPIA: Verify each Critical-tier personal-data asset has a DPIA completed by a qualified reviewer (DPO or privacy engineer); check DPO sign-off record is on file. - % SR-Software REMs cross-referencing SR-Data REM: Pull last 30 days of SR-Software REM completions; confirm cross-reference field is populated for Critical/High Software artifacts.

Evidence Location: __ Validation Date: __ Notes: ___

Question 6: Continuous REM-evidence validation and cross-domain linkage

Q6.1: Are Critical-tier REMs re-validated against observed reality at least quarterly and High-tier at least semi-annually, with validation deltas routed to IM-Data as findings, no Critical-tier accepted gap aging beyond 60 days without documented escalation, and SR-Software cross-reference operating for Critical/High Software artifacts?

Evidence Required: - [ ] REM validation log exists and shows at least one completed validation run for every Critical-tier asset in the last 90 days, using observable reality checks (data-catalog, admin-console, audit log, IR findings, ML monitoring) - [ ] Validation method documented: stratified sample of at least one row per base category (classification, consent/lawful basis, lineage, retention, cross-border flows, encryption, access control, no-train assertions, DSAR) per asset - [ ] Validation deltas (row claimed Met but evidence fails re-validation) are routed to IM-Data as findings with severity tags and remediation SLAs matching the asset's tier - [ ] Accepted-gaps register shows no Critical-tier gap past 60 days without a documented escalation record naming the program sponsor - [ ] Cross-domain linkage health is monitored: no Critical-tier data asset actively consumed by a Software artifact whose SR-Software REM lacks the SR-Data cross-reference - [ ] REM-population status per asset reflects the last validation date and outcome for each Critical/High-tier asset - [ ] GDPR supervisory authority guidance updates and adequacy-decision status changes trigger auto-flagging of cross-border-flow REM rows within 5 business days

Metric Collection Guidance: - % Critical-tier REMs re-validated: Pull REM validation log; count Critical-tier assets with a validation run recorded in the last 90 days using observable-reality checks (not self-report). Formula: validated Critical-tier assets / total Critical-tier assets × 100. - Accepted-gap aging (Critical): Confirm the 60-day SLA is enforced; spot-check any gap older than 60 days for an escalation record; zero exceptions without documented escalation. - Validation delta routing: Confirm IM-Data backlog contains findings originating from REM validation deltas in the last 90 days. - DPIA currency: Confirm all Critical-tier personal-data DPIAs have been reviewed within the last 12 months or since last material change. - SR-Software cross-reference health: Confirm no Critical-tier data asset consumed by a Software artifact has a missing SR-Data cross-reference in the consuming Software artifact's REM.

Evidence Location: __ Validation Date: __ Notes: ___

Maturity Level 3

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

Question 7: Machine-readable pack and pipeline attestation

Q7.1: Is the AI/HAI Data Requirements Pack expressed in a machine-readable schema (JSON or YAML), and do Critical-tier data asset pipeline deploys fail the gate when a REM requirement check fails?

Evidence Required: - [ ] Machine-readable requirements pack published (JSON or YAML schema); each requirement has: ID, machine-readable evidence type (data-catalog-query / config-check / audit-log-query / test-result-reference / manual-attestation), acceptance predicate, and tier applicability field - [ ] Pipeline deploy gate for Critical-tier assets includes automated REM checks: classification label confirmed in data catalog; encryption-at-rest confirmed; no-train setting confirmed via vendor admin-console API; access control RBAC confirmed; retention policy confirmed active; cross-border flow mechanism confirmed current - [ ] Failed REM check blocks the pipeline deploy for Critical-tier assets; evidence of at least one blocked deploy or a test of the block is on file - [ ] Passed REM checks write a signed attestation to the REM record; attestation log is queryable - [ ] REM-population status per asset is updated automatically from pipeline attestation results for automated evidence types - [ ] Pack published under a permissive license with external adoption tracking (forks, citations, downloads logged) - [ ] Pack-version control aligns the public version with the internal version; no version lag exceeding one quarter

Outcome Metrics: | Metric | Baseline | Current | Target | Met? | Notes | |--------|----------|---------|--------|------|-------| | % Critical-tier REM requirements with automated pipeline attestation at deploy time | measure | % | ≥80% | ☐ | Pipeline attestation log | | % REM evidence rows auto-validated (vs. manual-only) | measure | % | ≥70% | ☐ | Validation telemetry | | Pipeline deploy blocks triggered by failed Critical-tier REM check | measure | ___ | tracked; zero silent failures | ☐ | Pipeline telemetry | | Pack adoption (forks, citations, downloads of published artifact) | 0 | ___ | tracked, trending up | ☐ | External telemetry | | Industry-standard contributions per year | 0 | ___ | ≥2 | ☐ | Contribution log |

Metric Collection Guidance: - % Critical-tier requirements with pipeline attestation: Count Critical-tier REM requirement rows with an automated pipeline check vs. total Critical-tier requirement rows. Formula: automated Critical-tier rows / total Critical-tier rows × 100. - % REM rows auto-validated: Count all REM rows where the last validation was performed by an automated check vs. total rows. Formula: auto-validated rows / total rows × 100. - Pipeline deploy blocks: Count blocked pipeline deploys in the last 90 days where the block was triggered by a failed Critical-tier REM check; confirm zero silent failures. - Pack adoption: Query external telemetry for the published pack artifact; confirm an upward trend. - Industry-standard contributions: Count substantive contributions to OpenSSF AI / OWASP LLM / DAMA / NIST AI RMF Playbook in the last 12 months.

Evidence Location: __ Validation Date: __ Notes: ___

Question 8: Automated REM-evidence validation from runtime signals

Q8.1: Are ≥70% of REM evidence rows auto-validated via pipeline signals, runtime monitoring (ML-Data), admin-console API ingestion, and adequacy-decision status feeds, with automation error-rate monitored and human review reserved for DPIA sign-off, DSAR complex cases, and accepted-gap escalations?

Evidence Required: - [ ] REM validation pipeline is subscribed to ML-Data monitoring outputs (access-audit log completeness signal, no-train re-verification output, retention-enforcement run results) and routes failures to the correct REM rows - [ ] IM-Data incident records feed the REM validation pipeline: post-incident reviews touching a pack requirement auto-flag the relevant REM rows for re-validation - [ ] SM inventory change events (tier upgrade) auto-trigger a full REM re-validation run under the new tier's requirements depth - [ ] GDPR supervisory authority guidance updates and adequacy-decision status changes auto-flag cross-border-flow REM rows within a defined SLA - [ ] Automation error-rate (false-positive and false-negative failures) is monitored; a defined threshold triggers human review of the affected check - [ ] Human review queue is bounded: DPIA sign-off, DSAR complex cases, and accepted-gap escalations remain for manual handling; all other evidence types are auto-validated - [ ] REM-population status per asset reflects auto-validated rows separately from manual-attestation rows; staleness of each auto-validated row is tracked

Metric Collection Guidance: - % auto-validated rows: Pull validation telemetry; count rows with an auto-validation result in the last 90 days vs. total active REM rows. Confirm the 70% target is met across both Critical and High-tier assets. - Automation error-rate: Query the pipeline's false-positive log and false-negative log; threshold for human review should be documented. - Human review queue: Confirm the queue contains only DPIA sign-off, DSAR complex cases, and accepted-gap escalations; no other row types should be pending manual review for more than the defined SLA. - Pipeline gate: Confirm the pipeline is still enforcing the gate from Q7; zero silent failures. - Adequacy-decision feed: Verify the pipeline received at least one adequacy-decision status signal in the last 90 days (or confirm no changes occurred and the check was made).

Evidence Location: __ Validation Date: __ Notes: ___

Question 9: Standards contribution

Q9.1: Has the program contributed at least two substantive artifacts per year to recognized standards bodies, with contributions publicly documented and traceable to adoption in OpenSSF AI, OWASP LLM, DAMA / EDM Council, or NIST AI RMF Playbook?

Evidence Required: - [ ] Contribution log lists at least 2 substantive contributions in the last 12 months with: body name, contribution type, submission date, and a link or reference to the external artifact - [ ] Contributions are legally vetted (internal legal review record on file) and anonymized or attributed per the org's disclosure policy - [ ] At least one contribution is a machine-readable artifact (data-archetype REM schema, JSON schema for data requirements, or equivalent) rather than commentary only - [ ] External adoption is tracked: at least one contribution has a confirmed path to adoption (working group vote, draft inclusion, or citation in a published document) - [ ] Pack and REM schema published under a permissive license with version aligned to the internal version; no version lag exceeding one quarter - [ ] DAMA / EDM Council AI Data Governance working group engagement is documented if applicable to the org's sector - [ ] Contribution pipeline has ≥2 contributions in-flight at any given time

Metric Collection Guidance: - Industry-standard contributions: Count contributions in the last 12 months in the contribution log; confirm each has a body name, submission date, and external reference link. Minimum 2 to meet target. - Pack adoption: Confirm external telemetry shows an upward trend in forks, citations, or downloads; a flat or declining trend is a gap signal. - Contribution pipeline health: Confirm ≥2 contributions are actively in-flight. - Version alignment: Confirm the public pack version tag matches the current internal version tag. - L3 automation goals: Confirm the pipeline attestation and auto-validation goals from Q7 and Q8 remain met.

Evidence Location: __ Validation Date: __ Notes: ___

Summary Scorecard

Question	Activity	Score
Q1	L1-A: Base data requirements pack	☐ 1.0 / ☐ 0.67 / ☐ 0.33 / ☐ 0.0
Q2	L1-B: Per-archetype deltas	☐ 1.0 / ☐ 0.67 / ☐ 0.33 / ☐ 0.0
Q3	L1-C: SM intake gate + REM per asset	☐ 1.0 / ☐ 0.67 / ☐ 0.33 / ☐ 0.0
Q4	L2-A: Quantitative and binary pack	☐ 1.0 / ☐ 0.67 / ☐ 0.33 / ☐ 0.0
Q5	L2-B: Per-tier requirement depth	☐ 1.0 / ☐ 0.67 / ☐ 0.33 / ☐ 0.0
Q6	L2-C: Continuous REM-evidence validation + cross-domain linkage	☐ 1.0 / ☐ 0.67 / ☐ 0.33 / ☐ 0.0
Q7	L3-A: Machine-readable pack + pipeline attestation	☐ 1.0 / ☐ 0.67 / ☐ 0.33 / ☐ 0.0
Q8	L3-B: Automated REM-evidence from runtime signals	☐ 1.0 / ☐ 0.67 / ☐ 0.33 / ☐ 0.0
Q9	L3-C: Standards contribution	☐ 1.0 / ☐ 0.67 / ☐ 0.33 / ☐ 0.0
Total		___ / 9.0

Achieved Maturity Level: ☐ Not Started / ☐ Level 1 / ☐ Level 2 / ☐ Level 3

Document Version: HAIAMM v3.0 Practice: Security Requirements (SR) Domain: Data Questionnaire Authored: 2026-05-15 Author: Verifhai

Instructions:

Answer based on current practices, not plans
“Yes” requires documented evidence
Complete all Level 1 questions before Level 2
Partial implementation = “No”

↓ Download as Markdown