EnaGuard
Mapped to trusted frameworks without becoming a framework summary
EnaGuard uses international standards and technical references to make its assessment language defensible. The public crosswalk explains the basis; the protected control criteria and scoring logic remain inside the methodology.
The crosswalk is a translation layer, not a checklist
EnaGuard starts with recognized governance, risk, security, and resilience language, then translates it into evidence questions that can be reviewed against real AI architecture.
Governance intent
What decision, accountability question, or oversight obligation must the assessment support?
Risk context
Industry, deployment model, autonomy, data sensitivity, and impact level define the lens.
Architecture evidence
Inventories, flows, controls, logs, tests, metrics, and incident records become reviewable artifacts.
Challenge
Evidence is tested against production, failure, security pressure, and governance scrutiny.
Claim boundary
The report says only what scope, evidence, sampling, challenge, and QA can defend.
Common language for risk, security, governance, and verification
These references shape the vocabulary of the assessment. They do not replace EnaGuard methodology, and they are not used as claims of certification, approval, or endorsement.
ISO/IEC 42001, 23894, 5338, 38507, 42005 and related AI standards
Used to frame management-system expectations, AI risk processes, governance responsibilities, lifecycle concerns, and board-level technology governance.
NIST AI Risk Management Framework and Generative AI Profile
Used to connect governance, mapping, measurement, and management language to concrete evidence expectations.
OWASP LLM and Agentic Security guidance
Used to inform prompt injection, sensitive data exposure, agent permissions, tool use, and control-testing language.
MITRE ATLAS adversarial AI knowledge base
Used as a threat-informed lens for how AI systems can be attacked, manipulated, or abused.
Cloud Security Alliance AI Controls Matrix
Used as a reference relationship for cloud, data, identity, monitoring, and provider-control conversations.
EU AI Act and industry regulatory expectations
Used to keep classification, documentation, transparency, human oversight, and traceability in view without providing legal advice.
The useful question is what each reference helps you see
Roles, accountability, and oversight
Framework language becomes a check on who owns the AI system, who approves risk, who monitors exceptions, and who can stop or escalate.
Evidence question: can those ownership and approval paths be shown in the live operating model?
Controls, attacks, and resilience
Security references become testable expectations around identity, access, prompt injection, data lineage, model gateways, logging, and fallback.
Evidence question: what proves the control worked under load, failure, or attack?
Boundaries, confidence, and action
The assessment result must distinguish what is observed, what is sampled, what is out of scope, and what remains an unresolved risk.
Evidence question: is the claim strong enough for the evidence available today?
We share the basis and report logic; we protect detailed scoring rules
Public
Architecture layers, risk areas, executive questions, industry determinants, the five-level evidence model, general evidence-ceiling logic, report logic, AI governance evidence themes, and axis-level framework mapping.
Protected
Exact probe set, control weights, control-specific evidence caps, acceptance thresholds, normalization rules, benchmark data, challenge protocols, and final report templates.
Rule
Public material explains what is assessed, what evidence supports the conclusion, and how it can be challenged. Protected material covers exact weights, thresholds, and execution detail.
Use the crosswalk to ask better questions, not to self-certify
Vocabulary
The Methodology Basis gives leadership, audit, risk, security, and architecture teams a shared language for AI governance and AI architecture risk.
Scoping
It helps decide whether the next step should be Signal, Focus, or Verify, depending on the depth of evidence the decision requires.
Boundary
It shows the methodological basis without implying legal advice, certification, standard-body approval, or public disclosure of EnaGuard scoring logic.
“Mapped to” is the right language. “Certified by” is not.
EnaGuard can describe its methodology as cross-mapped to recognized AI governance, risk, security, and verification references once the relevant crosswalk is published. It should not imply that a standards body has approved the assessment methodology. For a practical governance view, see the AI Governance Evidence Map.