External Mapping Model

This section defines how aws2 should relate to external standards, frameworks, guidance, vulnerability scoring systems, and threat taxonomies. It is informative in this working draft.

aws2 should map to and complement existing work. It should not claim equivalence to an external source unless a future detailed crosswalk, release process, and claim rule explicitly support that statement.

10.1 Mapping Record Fields

Each detailed mapping record SHOULD include:

• aws2 family or candidate requirement
• external source name
• source owner or publisher
• source version, status, publication date, or maturity state where available
• source URL or stable reference
• access date
• source signal or requirement summary
• mapping posture
• aws2 layer
• primary responsibility owner
• evidence angle
• claim limit

Mapping records should be traceable to primary sources when current maturity, version, status, certification posture, or regulatory meaning matters.

10.2 Mapping Postures

aws2 uses the following mapping postures.

Informs:

• the source shaped design thinking or vocabulary
• no row-by-row control relationship is claimed
• acceptable phrasing: " aws2 is informed by this source"

Candidate control:

• the source contains a requirement, control objective, threat, mitigation, or assurance pattern that can shape a candidate aws2 requirement
• acceptable phrasing: "this source maps to a candidate aws2 control"

Supports evidence for:

• the source helps define useful proof artifacts, evidence state, review cadence, or governance records
• acceptable phrasing: "this artifact supports evidence for selected candidate controls"

Advisory input:

• the source is useful for threat framing, design review, prioritization, or scenario testing, but should not be treated as a direct requirement
• acceptable phrasing: "this source informs review scenarios"

Out of scope:

• the source topic does not materially apply to the scoped aws2 boundary, or belongs to a separate legal, sectoral, model-training, enterprise-security, or governance domain
• acceptable phrasing: "not mapped for this scoped system"

Implementation-specific mapping:

• a concrete system implements, produces evidence for, or inherits selected controls
• acceptable phrasing: "implements selected controls for the named scoped system"

10.3 Initial Mapping Sources

The first working-draft mapping baseline distinguishes mapped sources from context-only sources.

Mapped sources currently represented in Appendix C rows:

• OWASP Artificial Intelligence Security Verification Standard
• OWASP Agentic Skills Top 10
• OWASP AI Vulnerability Scoring System
• Cloud Security Alliance Autonomous Action Runtime Management
• Cloud Security Alliance AI Controls Matrix
• Cloud Security Alliance MAESTRO
• NIST AI Risk Management Framework
• NIST AI 600-1
• ISO/IEC 42001
• ISO/IEC 23894
• AIUC-1
• Five Eyes guidance on careful adoption of agentic AI services
• MITRE ATLAS
• EU AI Act

Context-only sources currently used for orientation, analogy, or source discovery until specific family-level mapping rows are added:

• CryptoCurrency Security Standard
• OWASP Agentic AI Threats and Mitigations
• NIST AI Agent Standards Initiative

These lists are not claims that every source is equally normative, equally current, or fully covered. Detailed mapping rows must preserve source status and claim limits.

10.4 Mapping Use Rules

Mapping rows SHOULD be used to:

• explain how aws2 candidate controls relate to existing work
• identify external source signals that shaped candidate requirements
• identify evidence artifacts that could support selected controls
• preserve claim limits for legal, certification, management-system, or source-specific statements
• find gaps where aws2 should defer to an external standard rather than duplicate it

Mapping rows MUST NOT be used to claim:

• full external-framework coverage
• legal compliance
• certification under an external program
• endorsement by an external standards body
• equivalence between aws2 and any mapped source
• complete security effectiveness for a scoped system

10.5 Mapping Maintenance

Mappings SHOULD be rechecked when:

• an external source changes maturity, version, release status, or claim posture
• an aws2 control family changes materially
• a new release profile is proposed
• a public claim depends on the mapping
• a legal, regulatory, or certification statement could be inferred from the mapping

Access dates should remain visible in mapping notes and source registers. Where a source is paywalled, high-level, or not fully public, the mapping must state that limitation.