Family Guides
AWS2-GOV: Governance, Exceptions, And Change Management
AWS2-GOV is about making sure the organization owns the risk decisions around agentic work.
In ordinary business terms, this family asks: who is allowed to approve the agentic workspace boundary, who accepts exceptions, who decides when a system must be reviewed again, who checks supplier or provider changes, and who stops the organization from saying more than the evidence supports?
This matters because agentic workspace systems rarely fail only because of one technical setting. A team might have a reasonable sandbox, approval gate, log, source review, or validation packet, but still overclaim readiness, forget an exception, expand authority without review, miss a provider change, or let public wording imply compliance or certification that does not exist. AWS2-GOV turns those decisions into owner records, exception records, change gates, review triggers, reassessment packets, training records, supplier review notes, and claim limits.
What This Family Covers
In scope:
- Governance owner or owner-group records for the scoped system, target level, claim limits, external mapping statements, and known gaps.
- Exception, assumption, risk acceptance, expiry, review-date, evidence-basis, remediation, and claim-impact records.
- Conservative claim-language review for internal assurance discussions, security questionnaires, public copy, partner discussions, procurement statements, and external mapping statements.
- Review cadence and trigger-based reassessment for production systems, boundary changes, new high-impact authority, new trusted sources, material policy changes, supplier or provider changes, standards changes, incidents, validation findings, and recurring management review.
- Coordinated review before expanding agent authority, accepting persistent exceptions, changing high-impact suppliers or sources, or making external mapping statements.
- Separated, independent, or qualified review for high-assurance changes and persistent exceptions where feasible.
- Governance exercises for incident escalation, emergency stop, rollback, evidence access, exception expiry, reassessment, and disclosure or notification routing.
- AI literacy, role-specific training, procurement due diligence, supplier due diligence, and governance records that support later review.
Out of scope:
- Creating an
aws2certification program, public governance body, auditor program, assessor qualification model, or endorsement process. - Proving legal compliance, regulatory sufficiency, ISO/IEC 42001 certification, EU AI Act conformity, privacy-law compliance, SOC 2 coverage, CSA STAR for AI status, or any other external assurance claim.
- Replacing technical controls, runtime enforcement, source review, logging, validation, incident response, procurement, legal review, or privacy review.
- Treating a generic GRC ticket, spreadsheet, dashboard, meeting note, or training completion record as sufficient unless it links to scoped evidence, owners, dates, review decisions, and claim limits.
- Using supplier, provider, or tool marketing claims as proof of local governance effectiveness.
Level Summary
Levels are cumulative. Level 2 builds on Level 1, and Level 3 builds on both.
| Level | Plain-language meaning | Why this level exists | Typical evidence |
|---|---|---|---|
| Level 1 | The organization names who owns the governance decision, records material exceptions and assumptions, and avoids unsupported claims. | A scoped system cannot be governed honestly if nobody owns the boundary, target level, known gaps, or wording limits. | Governance owner record, boundary or target-level signoff, exception note, assumption log, risk acceptance, claim-limit record. |
| Level 2 | Production or expanded use has a review cadence or trigger process, a stronger exception register, and coordinated owner review before material expansion or external mapping statements. | Managed use needs repeatable governance, not one-off approvals that become stale after source, supplier, policy, boundary, or validation changes. | Review trigger policy, change ticket, exception and risk register, remediation plan, supplier review, coordinated expansion approval, mapping review. |
| Level 3 | High-impact governance changes receive separated or independent challenge where feasible, governance procedures are exercised, and reassessment is tied to releases, providers, incidents, standards, regulatory changes, and management review. | High-assurance environments need stronger challenge, exercised procedures, and active reassessment when material conditions change. | Reviewer independence note, challenge findings, exercise packet, evidence-access test, reassessment plan, trigger log, management review, updated claim limits. |
Candidate Controls
AWS2-GOV-L1-001: Governance Owner And Claim Accountability Level 1
Requirement summary
Identify the governance owner or owner group responsible for accepting the scoped system boundary, target level, claim limits, external mapping statements, and known gaps.
Why it exists
Agentic workspace risks cross technical and non-technical boundaries. A runtime owner may understand approvals, a workspace owner may understand files and apps, a source owner may understand tools and connectors, and a legal or risk owner may understand claims. Without an accountable governance owner, each group can assume someone else accepted the risk.
Why this level
This belongs at Level 1 because accountability is the minimum starting point for honest governance. The owner record does not require advanced tooling, but it must make clear who can accept or reject the boundary, target level, known gaps, and claim posture.
Evidence examples
| Evidence | Likely owner/provider | When collected | What it should show | Claim limit |
|---|---|---|---|---|
| Governance owner record | Governance, risk, security, compliance, or business owner | Before internal assurance discussion and after owner changes | Owner or owner group, role, scoped system, boundary accepted, target level, responsibilities, and review date | Names accountability; does not prove the technical controls work. |
| Boundary and target-level approval | Governance owner with AWS2-SCP and evidence owners | Before production use, material expansion, or mapping statements | Scoped system name, included and excluded resources, intended target level, known gaps, and approver | Supports boundary decision; does not prove readiness for the target level. |
| Claim-accountability signoff | Governance owner with legal, security, or evidence reviewer as applicable | Before external or assurance-facing wording is used | Approved claim verbs, prohibited claims, mapped source set, evidence basis, and expiry or review trigger | Controls wording; does not create certification, legal compliance, or endorsement. |
AWS2-GOV-L1-002: Exceptions, Assumptions, And Risk Acceptances Level 1
Requirement summary
Document exceptions, assumptions, and risk acceptances that materially affect candidate control interpretation, including owner, rationale, and expiry or review date where applicable.
Why it exists
A control may look complete only because an assumption is hidden. For example, a team may assume users will not connect personal accounts, that a provider log is complete, that a supplier will notify about changes, or that a local agent cannot reach a sensitive folder. Material exceptions and assumptions must be visible before any claim can be trusted.
Why this level
This belongs at Level 1 because transparent exception and assumption records are required before stronger review, remediation, or independent challenge can make sense.
Evidence examples
| Evidence | Likely owner/provider | When collected | What it should show | Claim limit |
|---|---|---|---|---|
| Exception record | Governance or risk owner with affected control owner | When a control cannot be met as written or a material workaround is used | Control ID, exception, owner, rationale, affected scope, evidence basis, expiry or review date, and remediation plan if applicable | Shows an exception exists; does not make the risk acceptable by itself. |
| Assumption log | Governance or evidence owner | During scope definition, validation, mapping, and review | Assumption, affected controls, evidence basis, owner, and trigger for recheck | Makes uncertainty visible; does not prove the assumption is true. |
| Risk acceptance note | Governance owner with business and security input | When a material gap is accepted instead of immediately remediated | Residual risk, rationale, compensating controls, owner, review date, and claim limits | Supports decision review; does not prove legal, regulatory, or business sufficiency outside the named scope. |
AWS2-GOV-L1-003: Conservative Claim Language Level 1
Requirement summary
Use conservative claim language for working-draft use and do not claim aws2 compliance, certification, legal compliance, approval, endorsement, or complete coverage of any external standard.
Why it exists
Overclaiming is one of the easiest governance failures to create. A draft control profile, crosswalk, validation packet, GRC score, or vendor feature can be misread as compliance, certification, complete coverage, or external approval. This control keeps wording tied to actual evidence and current aws2 status.
Why this level
This belongs at Level 1 because careful wording is required immediately, even before production maturity. The working draft has no public conformance scheme, so every assurance-facing statement must stay bounded.
Evidence examples
| Evidence | Likely owner/provider | When collected | What it should show | Claim limit |
|---|---|---|---|---|
| Approved claim statement | Governance, legal, security, or evidence owner | Before internal assurance, procurement, partner, public, or sales use | Exact wording, named scope, evidence basis, reviewer, date, and prohibited stronger claims | Supports bounded wording only; does not prove the underlying controls. |
| Prohibited-claims list | Governance or legal owner | Before publication or questionnaire response and after posture changes | Phrases to avoid, such as compliance, certification, endorsement, approval, complete coverage, or legal sufficiency | Blocks overclaiming; does not remediate gaps. |
| External mapping review record | Governance owner with evidence or crosswalk owner | Before using source mappings in external statements | External sources named, mapping posture, evidence angle, claim limit, and reviewer decision | Supports selected mapping statements; does not prove external-framework compliance. |
AWS2-GOV-L2-001: Review Cadence And Trigger-Based Review Level 2
Requirement summary
Define a review cadence or trigger-based review process for production systems, including boundary changes, new high-impact action authority, new trusted sources, material policy changes, supplier or provider changes, external standards changes, and unresolved validation findings.
Why it exists
Governance goes stale quickly. Models, prompts, tools, connectors, memory sources, policies, logs, providers, suppliers, standards, laws, and business workflows can change after the first approval. A production system needs a defined way to decide when review is required again.
Why this level
This belongs at Level 2 because production or managed use needs repeatable governance. Level 1 can record a snapshot; Level 2 must define how the snapshot is refreshed when material changes occur.
Evidence examples
| Evidence | Likely owner/provider | When collected | What it should show | Claim limit |
|---|---|---|---|---|
| Review cadence policy | Governance or risk owner | Before production use and after cadence changes | Review frequency, covered systems, owners, evidence sources, and escalation path | Defines cadence; does not prove reviews happen or are effective. |
| Reassessment trigger catalog | Governance owner with runtime, source, context, validation, and evidence owners | Before production use and after trigger updates | Boundary, authority, source, policy, provider, standards, regulatory, incident, finding, and claim-change triggers | Identifies triggers; does not prove every trigger will be detected. |
| Change review record | Change owner, release owner, or governance owner | When a material change occurs | Change summary, affected controls, evidence impact, review decision, owner, and follow-up date | Supports one review decision; does not prove unchanged areas are safe. |
AWS2-GOV-L2-002: Material Exception And Risk Register Level 2
Requirement summary
Maintain an exception and risk acceptance register for material gaps, including owner, rationale, expiry or review date, evidence basis, claim limit, and remediation plan where applicable.
Why it exists
Informal exception notes are easy to lose. A production system needs a durable register that lets reviewers find material gaps, see who owns them, understand why they were accepted, know when they expire, and know which claims must be narrowed while they remain open.
Why this level
This belongs at Level 2 because the register turns Level 1 exception awareness into managed governance. It is especially important where exceptions affect production, high-impact authority, sensitive data, source trust, logs, validation, or external wording.
Evidence examples
| Evidence | Likely owner/provider | When collected | What it should show | Claim limit |
|---|---|---|---|---|
| Exception and risk register | Governance, risk, compliance, or security owner | Continuously for production systems and at each review checkpoint | Exception ID, affected controls, scope, owner, rationale, evidence basis, expiry, remediation, risk acceptance, status, and claim limit | Tracks material gaps; does not prove accepted risks are acceptable outside the named scope. |
| Remediation plan | Control owner with governance owner | When a material gap requires remediation | Actions, owner, target date, dependencies, validation or retest trigger, and closure evidence | Defines work; does not prove remediation succeeded. |
| Claim-impact record | Governance or evidence owner | When an exception affects wording or external mapping | Claims blocked, narrowed, delayed, or allowed with conditions because of the exception | Keeps wording bounded; does not fix the exception. |
AWS2-GOV-L2-003: Coordinated Expansion And Mapping Review Level 2
Requirement summary
Coordinate security, risk, business, runtime, workspace, source, and evidence owners before expanding agent authority, accepting persistent exceptions, changing high-impact suppliers or sources, or making external mapping statements.
Why it exists
Agent authority expansion can look small in one system and large in another. A new connector, source package, MCP server, memory source, repository permission, sensitive data class, or external mapping claim can affect runtime controls, source trust, logs, validation, data handling, and business risk at the same time.
Why this level
This belongs at Level 2 because managed production change requires the right owners to review together. It is not enough for one admin or business owner to approve broader authority without evidence and claim review.
Evidence examples
| Evidence | Likely owner/provider | When collected | What it should show | Claim limit |
|---|---|---|---|---|
| Coordinated expansion approval | Governance owner with business, security, runtime, workspace, source, and evidence owners | Before material authority, boundary, source, supplier, or mapping expansion | Scope change, affected controls, owner roles, evidence reviewed, open gaps, decision, and conditions | Supports one expansion decision; does not prove implementation matched the approval. |
| Supplier or source change review | Procurement, security, source, or governance owner | Before high-impact supplier/source changes and after provider notices | Supplier/source identity, change summary, due diligence, source-trust evidence, affected permissions, and risk decision | Supports due diligence; does not prove supplier security or source integrity. |
| External mapping approval | Governance owner with crosswalk or evidence owner | Before external source mappings are used in public or customer-facing material | Source mapped, mapping posture, evidence basis, claim limits, reviewer, and allowed wording | Supports bounded mapping; does not prove external-framework compliance. |
AWS2-GOV-L3-001: Separated Or Independent Review Level 3
Requirement summary
Require separated or independent review for high-assurance deployment changes, persistent exceptions, high-impact source or supplier changes, and material claim-language or external-mapping changes.
Why it exists
Builders, product owners, and business sponsors may have incentives to accept risk quickly or use stronger claims than the evidence supports. Separated review provides challenge for high-impact decisions, persistent exceptions, supplier/source changes, and material public wording.
Why this level
This belongs at Level 3 because high-assurance governance needs more than self-approval. The standard draft does not define an aws2 assessor or independence model yet, so the evidence should record the reviewer relationship and qualification basis without implying certification.
Evidence examples
| Evidence | Likely owner/provider | When collected | What it should show | Claim limit |
|---|---|---|---|---|
| Separated reviewer assignment | Governance, audit, security, risk, or review lead | Before high-assurance review starts | Reviewer role, relationship to build or business owner, conflicts, scope, and review mandate | Shows separation basis; does not prove formal auditor independence. |
| Reviewer qualification basis | Governance or review lead | Before relying on the review decision | Relevant experience, role, training, internal audit responsibility, red-team responsibility, legal/risk role, or external engagement scope | Supports reviewer selection; does not create an aws2 assessor credential. |
| Challenge review summary | Separated reviewer or review group | At review completion | Evidence challenged, assumptions questioned, findings opened, decisions accepted or rejected, and management response | Supports stronger review; does not prove complete control effectiveness. |
AWS2-GOV-L3-002: Governance Procedure Exercises Level 3
Requirement summary
Test governance procedures for incident escalation, emergency stop, rollback, exception expiry, reassessment, evidence access, and disclosure or notification decision routing in high-impact environments.
Why it exists
Governance procedures often look adequate until a real incident, urgent stop decision, rollback, evidence request, exception expiry, or disclosure question arrives. Exercises show whether owners can find evidence, make decisions, route escalation, and identify gaps without exposing raw sensitive payloads unnecessarily.
Why this level
This belongs at Level 3 because high-impact environments need practiced governance, not only written policies. Exercises should be scoped, safe, and tied to findings and retests.
Evidence examples
| Evidence | Likely owner/provider | When collected | What it should show | Claim limit |
|---|---|---|---|---|
| Governance exercise plan | Governance, incident, evidence, or risk owner | Before exercise execution and after scenario updates | Scenario, roles, covered controls, evidence requested, expected decisions, and safety boundaries | Defines an exercise; does not prove procedures worked. |
| Exercise decision log | Governance or incident owner with evidence owner | During or immediately after the exercise | Decisions, escalations, evidence retrieved, stop or rollback path, disclosure routing, findings, and owners | Tests decision-making; does not prove live technical controls operated in production. |
| Evidence-access test result | Evidence, log, validation, runtime, or governance owner | During governance exercises and after evidence-store changes | Whether required AWS2-RUN, AWS2-LOG, AWS2-VAL, AWS2-SEC, AWS2-SRC, and AWS2-GOV evidence was located without exposing raw sensitive payloads | Supports evidence retrieval; does not prove all required evidence exists for every workflow. |
AWS2-GOV-L3-003: Formal Reassessment Process Level 3
Requirement summary
Maintain a formal reassessment process tied to release changes, provider changes, external standards changes, material incidents, control failures, regulatory changes, and recurring management review.
Why it exists
A high-impact agentic workspace system can become materially different after a provider feature change, model update, source update, connector change, policy change, new standard version, legal development, incident, failed control, or management decision. Formal reassessment prevents stale approvals and stale claims from becoming the default.
Why this level
This belongs at Level 3 because formal reassessment is a stronger governance commitment. It requires monitoring for triggers, assigning owners, reviewing evidence, updating claims, and recording management decisions.
Evidence examples
| Evidence | Likely owner/provider | When collected | What it should show | Claim limit |
|---|---|---|---|---|
| Formal reassessment procedure | Governance or risk owner | Before high-impact use and after process changes | Trigger sources, owners, required evidence, review steps, management review path, and closure criteria | Defines process; does not prove all triggers are detected. |
| Reassessment trigger log | Governance owner with source, runtime, validation, evidence, and legal/risk inputs | Continuously or at scheduled review checkpoints | Provider, release, source, policy, standards, regulatory, incident, validation, exception, and claim-change triggers | Shows known triggers; does not prove no other material triggers occurred. |
| Management review packet | Governance or executive owner | On schedule and after material incidents or reassessment triggers | Current risk posture, open exceptions, validation status, incidents, standards changes, claim limits, decisions, and follow-up owners | Supports governance review; does not prove legal compliance or certification. |
External Mapping Notes
The completed crosswalk treats AWS2-GOV as the organization-level family for accountable ownership, risk management, exception handling, training, review cadence, supplier or provider change review, external mapping review, and conservative claim language. Its main risk is overclaiming: governance records support bounded decisions and evidence review, but they do not create a release, certification path, legal compliance posture, or external endorsement.
Relevant external-source signals include:
- EU AI Act official sources inform selected governance, deployer or provider duty, AI literacy, quality-management, oversight, and review evidence angles, but
AWS2-GOVdoes not prove legal compliance, high-risk classification, conformity assessment, GPAI-provider compliance, or privacy sufficiency. - OWASP AISVS, OWASP Agentic Skills Top 10, and OWASP AIVSS inform human oversight, procurement or review orientation, installed-skill review, incident-response, risk scoring, prioritization, and remediation evidence, but they do not create an
aws2management system or certification path. - CSA AICM and CSA MAESTRO inform enterprise AI controls, responsibility mapping, assessment preparation, and layered threat-modeling review, but they are broader than agentic workspace governance and do not prove
aws2conformance. - NIST AI RMF 1.0 and NIST AI 600-1 strongly inform governance, accountability, risk culture, role assignment, disclosure, risk acceptance, and ongoing management, but they are not agentic-workspace-specific conformance standards.
- ISO/IEC 42001 and ISO/IEC 23894 inform management-system, risk-management, role-assignment, treatment, and review concepts, but no ISO certification claim exists without an actual accredited certification path.
- AIUC-1 is useful as a commercial comparator for scoped evidence, recurring testing, accountability, and governance posture, but
aws2does not create AIUC-1 certificate equivalence. - Five Eyes careful-adoption guidance informs adoption gates, accountability, low-risk-first rollout, rollback, and review triggers for agentic AI services, but it is not a conformance test suite or certification program.
- MITRE ATLAS informs adversary vocabulary, risk-register entries, scenario selection, and remediation prioritization, but it is not a governance framework by itself.
- The tooling research notes show that useful governance support exists across GRC platforms, compliance managers, AI admin consoles, release gates, supplier reviews, training systems, issue trackers, and manual workflows, but current tooling remains fragmented across products, local agents, coding agents, MCP-style servers, multimodal agents, supplier changes, evidence stores, and public claim review.
Formal Standard Link
Use this guide with the formal AWS2-GOV candidate requirements. If the guide and the standard draft disagree, the standard draft controls.