Lesson A17.9
Automation governance answers the questions that code cannot: Who owns the outcome? Who may approve a change? Who monitors evidence? Who accepts an exception? Who can disable the workflow? And who decides when it is time to retire it?
All organizations, automations, roles, decisions, metrics, exceptions, and lifecycle records in this lesson are fictional.
Lesson Progress
High School Advanced • A17: Security Automation Concepts • Lesson 9 of 10
Readiness Check
0/4 ready
Professional Hook
A workflow may be technically reliable today and still become unsafe later if nobody owns it. Sources change. Teams reorganize. Metrics drift. A ticket schema is renamed. An exception quietly expires. A temporary workaround becomes permanent. A trusted reviewer leaves.
Governance keeps those changes from silently rewriting the meaning of automation. It creates a durable connection between purpose, authority, evidence, ownership, review, and lifecycle.
The automation may execute the workflow, but people and governance remain accountable for the system.
Learning Objectives
Explain automation governance as the assignment of ownership, authority, evidence, review, change control, exception handling, monitoring, and lifecycle responsibility around defensive automation.
Distinguish the responsibilities of automation owners, control owners, evidence owners, workflow owners, risk or governance owners, approvers, analysts, and platform operators.
Design decision rights for approval, permissions, change review, exceptions, threshold changes, disabling, re-enabling, retirement, and risk acceptance without confusing technical access with authority.
Evaluate governance quality using accountability, separation of duties, evidence freshness, review cadence, metric ownership, change traceability, exception aging, and lifecycle completeness.
Build an Automation Governance Matrix that becomes the ninth artifact in the A17 Safe Automation Design and Governance Plan.
Governance Roles
Responsibility: Owns the overall automation outcome, scope, health, maintenance, and lifecycle.
Decisions: Proposes changes, coordinates reviews, responds to degradation, and ensures ownership remains current.
Evidence: Version history, health records, change requests, owner reviews, retirement records.
Responsibility: Owns how the automation fits into the defensive process, queue, ticket, and analyst workflow.
Decisions: Approves workflow-state logic, routing design, fallback, and operational handoffs.
Evidence: Workflow maps, routing decisions, exception history, SLA and state records.
Responsibility: Owns the intended defensive control objective the automation supports.
Decisions: Defines what success means and whether the automation still supports the control as designed.
Evidence: Control intent, control test results, evidence requirements, residual gaps.
Responsibility: Ensures records are attributable, complete, current, and available for review.
Decisions: Defines evidence fields, retention expectations, source quality, and evidence-health triggers.
Evidence: Log schema, source inventory, evidence completeness metrics, exception evidence.
Responsibility: Owns the fictional automation platform, integration reliability, permissions, and service health.
Decisions: Approves platform changes, monitors dependencies, and manages technical disable or degraded states.
Evidence: Platform health, dependency status, permission reviews, availability records.
Responsibility: Uses the automation output, applies judgment, records overrides, and reports workflow problems.
Decisions: Accepts, rejects, corrects, or escalates automation-supported outputs within assigned authority.
Evidence: Review notes, overrides, reason codes, analyst feedback, escalations.
Responsibility: Owns acceptance of residual risk, policy alignment, exception oversight, and material governance decisions.
Decisions: Approves exceptions, material scope changes, risk acceptance, and continued operation under known gaps.
Evidence: Exception approvals, risk decisions, governance reviews, review dates.
Responsibility: Provides explicit decision authority at defined human-gated workflow points.
Decisions: Approves, rejects, escalates, or requests more evidence for authority-sensitive transitions.
Evidence: Approver identity, evidence package, decision, rationale, timestamp.
Responsibility: Independently reviews proposed automation changes before they become active.
Decisions: Checks scope, permissions, failure behavior, metrics, evidence, and rollback or fallback readiness.
Evidence: Change review record, test summary, approvals, conditions, effective version.
Responsibility: Provides context on business criticality, operational dependencies, acceptable disruption, and service ownership.
Decisions: Confirms whether automation behavior still fits the service's business context.
Evidence: Service mapping, dependency statement, ownership confirmation, business-impact notes.
Governance Domains
Ask: What problem does the automation solve? Which workflows and objects are in scope? What is explicitly out of scope?
Evidence: Approved purpose statement, boundary checklist, linked workflow records.
Reopen review when: New data, new action, new workflow, new business use, or new environment.
Ask: Which decisions may automation support, which may it make administratively, and which require human approval?
Evidence: Human-in-the-Loop Decision Matrix and approval records.
Reopen review when: New consequential transition or authority change.
Ask: What is the smallest conceptual permission set needed for the approved support task?
Evidence: Permission design, allowlists, environment boundaries, review results.
Reopen review when: Any request for broader access or a new write capability.
Ask: What proves the automation acted correctly, failed safely, and stayed within scope?
Evidence: Version, inputs, outputs, timestamps, error states, approvals, overrides.
Reopen review when: Evidence completeness drops or logging changes.
Ask: Which measures show value, safety, reliability, analyst impact, and governance health?
Evidence: Automation Value Scorecard.
Reopen review when: Metric threshold breach, unexplained trend, or loss of measurement confidence.
Ask: Who reviews changes to logic, sources, permissions, thresholds, dependencies, or fallback?
Evidence: Change request, test evidence, reviewer, approval, version, effective date.
Reopen review when: Any material automation change.
Ask: How are temporary deviations documented, approved, bounded, monitored, and closed?
Evidence: Exception ID, owner, rationale, scope, expiration, conditions, closure evidence.
Reopen review when: Any need to operate outside the normal approved rule.
Ask: How is automation introduced, reviewed, maintained, paused, re-enabled, retired, and archived?
Evidence: Lifecycle state, owner review, version history, retirement decision, replacement link.
Reopen review when: Ownership loss, replacement workflow, obsolete purpose, or repeated degradation.
Decision Rights
Strong governance avoids vague phrases like “the security team approves.” Different decisions need different owners. The person who maintains a script may not be the person authorized to accept risk or approve a high-impact transition.
Accountable
Automation Owner
Consulted
Workflow Owner, Control Owner, Risk / Governance Owner
Evidence required
Purpose, boundary, value hypothesis, safe fallback, owners.
Accountable
Workflow Owner
Consulted
Automation Owner, Change Reviewer
Evidence required
Change diff, synthetic test evidence, rollback/fallback plan.
Accountable
Platform Owner
Consulted
Automation Owner, Risk / Governance Owner, Change Reviewer
Evidence required
Purpose, least-privilege analysis, new boundary, risk review.
Accountable
Authorized Approver
Consulted
Analyst, Workflow Owner
Evidence required
Current evidence package, uncertainty, rationale, timestamp.
Accountable
Risk / Governance Owner
Consulted
Automation Owner, Control Owner, Evidence Owner
Evidence required
Exception scope, rationale, compensating control, owner, expiration.
Accountable
Platform Owner
Consulted
Automation Owner, Workflow Owner
Evidence required
Threshold breach, impact, fallback readiness, disable reason.
Accountable
Automation Owner
Consulted
Platform Owner, Change Reviewer, Workflow Owner
Evidence required
Root cause addressed, validation passed, metrics healthy, fallback ready.
Accountable
Automation Owner
Consulted
Workflow Owner, Business / Service Owner, Evidence Owner
Evidence required
Replacement or end-of-need rationale, final evidence, archive record.
Lifecycle
The automation idea exists but has not been approved for use.
Required evidence: Purpose, owner, scope, value hypothesis, boundary, initial risks.
Exit condition: Governance review approves design work.
Workflow logic, human boundaries, evidence, failure modes, metrics, and safeguards are documented.
Required evidence: A17 artifacts or equivalent design evidence.
Exit condition: Testing and independent change review are ready.
Synthetic testing confirms normal behavior, safe fallback, evidence, and monitoring.
Required evidence: Test results, failure tests, dry-run evidence, reviewer decision.
Exit condition: Authorized activation approval.
The fictional automation is approved for its bounded workflow purpose.
Required evidence: Current version, owners, metrics, permissions, evidence, fallback.
Exit condition: Continued review, degraded state, paused state, or retirement.
The automation remains partially usable but one or more dependencies or metrics are unhealthy.
Required evidence: Visible degraded indicator, affected scope, owner, fallback, review date.
Exit condition: Recovery validation or pause.
Automation is intentionally stopped while manual or alternate workflow handles the work.
Required evidence: Pause reason, owner, fallback, affected scope, re-enable criteria.
Exit condition: Validated re-enable or retirement.
A temporary approved deviation from the normal design is active.
Required evidence: Exception ID, scope, rationale, approval, expiration, compensating control.
Exit condition: Close exception, redesign, or retire.
The automation is no longer approved for active use.
Required evidence: Retirement decision, replacement link, evidence archive, permission removal confirmation conceptually.
Exit condition: No return without a new governance review.
Change Control
Examples: New branch, new routing rule, different duplicate threshold, new closure condition.
Review: Re-test affected behavior, failure modes, evidence, metrics, and human boundaries.
Examples: New enrichment source, changed schema, different owner directory.
Review: Reassess relevance, freshness, attribution, sensitivity, and failure behavior.
Examples: Read becomes write, new queue scope, broader object access.
Review: Reassess least privilege, impact, authorization, dry run, and rollback/fallback.
Examples: Threshold or target is changed.
Review: Document rationale and ensure targets are not being weakened simply because performance is poor.
Examples: Automation owner, workflow owner, or approver changes.
Review: Confirm responsibilities, access, review cadence, and unresolved exceptions transfer cleanly.
Examples: Automation is used for a different service or decision context.
Review: Treat as material scope review, not a minor configuration update.
Examples: Ticketing platform field, enrichment service, playbook catalog, or integration changes.
Review: Re-test compatibility, fallback, and evidence completeness.
Examples: New workflow supersedes the old one.
Review: Stop new use, archive evidence, update references, confirm replacement ownership.
Exception Governance
Exceptions are sometimes necessary when a source migration, dependency change, or temporary operational constraint prevents the normal rule from being met. The danger is allowing temporary deviations to become permanent simply because nobody revisits them.
Stable identifier for the governance exception.
Example: EXC-901
Shows what the approved automation would normally require.
Example: Routing accuracy must remain above 90%
Defines exactly what temporary difference is being approved.
Example: Continue at 88% while ownership source is repaired
Explains why the exception is necessary.
Example: Manual fallback would create a larger backlog during a short source migration
Limits the exception to specific workflows, queues, or records.
Example: Only fictional scheduling alerts
Defines extra review or protection while the exception exists.
Example: Mandatory analyst routing confirmation
Names who must remediate the exception.
Example: SOC Workflow Owner
Names the authority accepting temporary residual risk.
Example: Risk / Governance Owner
Prevents the exception from becoming permanent by default.
Example: 14 days
Defines what proves the exception is no longer needed.
Example: Routing source repaired and two healthy review windows
Governance Matrix Anatomy
Stable identifier for the governance record.
Example: GOV-A901
Names the fictional automation or workflow being governed.
Example: Northbridge Ticket Routing Automation
Names who owns the automation outcome.
Example: Automation Owner
Names who owns the operational process.
Example: SOC Workflow Owner
Names who owns evidence completeness and quality.
Example: Evidence Owner
Defines who may approve material or authority-sensitive decisions.
Example: Incident Response Lead
Defines routine governance review frequency.
Example: Monthly plus event-driven review
Links the automation to value and health measures.
Example: VAL-802, VAL-809, VAL-810
Defines what material change reopens governance review.
Example: New write permission or changed routing source
Defines who can stop the automation when safety or quality degrades.
Example: Platform Owner
Defines who may approve a temporary deviation.
Example: Risk / Governance Owner
Defines who closes the lifecycle when automation is no longer needed.
Example: Automation Owner
Fictional Governance Matrix
Linked evidence: OPP-101 / ENR-301 / BND-601 / FM-701 / VAL-801
Automation owner
Security Automation Engineer
Workflow owner
SOC Workflow Owner
Control owner
Detection Operations Owner
Evidence owner
Evidence Owner
Approver
Security Operations Lead
Review cadence
Monthly + source-change review
Key metrics
Time to usable evidence, stale-data rate, evidence completeness
Change triggers
New enrichment field, new source, new sensitivity, changed freshness threshold
Disable authority
Platform Owner may disable when required enrichment quality breaches threshold
Exception authority
Risk / Governance Owner
Linked evidence: OPP-102 / WFA-401 / WFA-402 / BND-603 / FM-702 / FM-703 / VAL-802
Automation owner
SOC Workflow Owner
Workflow owner
SOC Workflow Owner
Control owner
Security Operations Lead
Evidence owner
Evidence Owner
Approver
Security Operations Lead
Review cadence
Weekly operations + monthly governance
Key metrics
Routing accuracy, reassignment rate, duplicate rate, loop rate
Change triggers
Queue map, ownership source, routing rule, ticket schema, write scope
Disable authority
Platform Owner or SOC Workflow Owner on loop or duplicate threshold breach
Exception authority
Risk / Governance Owner
Linked evidence: OPP-104 / HITL-203 / PRB-501 / BND-602 / VAL-803
Automation owner
Incident Response Process Owner
Workflow owner
SOC Workflow Owner
Control owner
Incident Response Lead
Evidence owner
Evidence Owner
Approver
Incident Response Lead
Review cadence
Monthly + playbook-catalog change review
Key metrics
Recommendation acceptance, override reasons, analyst review time
Change triggers
New playbook, category mapping, branch logic, recommendation rule
Disable authority
Incident Response Process Owner if guidance becomes stale or misleading
Exception authority
Risk / Governance Owner
Linked evidence: HITL-204 / WFA-406 / BND-604 / FM-707 / VAL-810
Automation owner
Incident Response Lead
Workflow owner
Incident Response Lead
Control owner
Risk / Governance Owner
Evidence owner
Evidence Owner
Approver
Authorized Incident Response Lead
Review cadence
Every material change + monthly evidence review
Key metrics
Explicit approval completeness, timeout escalation quality
Change triggers
Authority map, approval states, timeout, evidence package schema
Disable authority
Immediate block if explicit approval completeness is below 100%
Exception authority
No exception to explicit approval requirement within A17
Linked evidence: OPP-106 / ENR-306 / BND-606 / FM-708 / VAL-806
Automation owner
Security Platform Owner
Workflow owner
Security Platform Owner
Control owner
Automation Owner
Evidence owner
Evidence Owner
Approver
Security Platform Owner
Review cadence
Weekly health + monthly threshold review
Key metrics
Failure rate, retry rate, fallback success, recovery time
Change triggers
Threshold, metric window, health source, disable criteria
Disable authority
Platform Owner
Exception authority
Risk / Governance Owner
Linked evidence: WFA-407 / PRB-504 / BND-605 / FM-703 / VAL-809
Automation owner
SOC Workflow Owner
Workflow owner
SOC Workflow Owner
Control owner
Security Operations Lead
Evidence owner
Evidence Owner
Approver
Security Operations Lead
Review cadence
Weekly exception aging review
Key metrics
Loop rate, exception age, reassignment, ownership resolution time
Change triggers
Loop threshold, fallback queue, ownership rule
Disable authority
Automatic routing stops at defined loop threshold
Exception authority
Risk / Governance Owner for temporary alternate routing
Linked evidence: WFA-408 / PRB-505 / FM-705 / VAL-808
Automation owner
SOC Workflow Owner
Workflow owner
SOC Workflow Owner
Control owner
Security Operations Lead
Evidence owner
Evidence Owner
Approver
Authorized Analyst
Review cadence
Monthly closure-quality review
Key metrics
Evidence completeness, reopen rate, closure-confirmation completeness
Change triggers
Closure criteria, required fields, approval rule
Disable authority
Stop auto-candidate transition when required evidence completeness drops
Exception authority
Risk / Governance Owner
Linked evidence: PRB-506 / FM-706
Automation owner
Security Operations Documentation Owner
Workflow owner
Incident Response Process Owner
Control owner
Security Operations Lead
Evidence owner
Evidence Owner
Approver
Documentation Owner
Review cadence
Monthly version-health review
Key metrics
Retired-version usage, broken-link rate, current-version coverage
Change triggers
Document retirement, replacement, dependency link update
Disable authority
Block retired versions from active recommendation immediately
Exception authority
No active-use exception for retired guidance
Fake Dashboard
Fictional ownership, approval, exception, lifecycle, and governance-health summary
Governed automations
8
Enrichment, routing, recommendations, approvals, health, exceptions, closure, and documentation
Human-gated
2
High-consequence approval and closure preserve explicit human authority
No-exception rules
2
Explicit approval and retired guidance cannot be bypassed within A17
Lifecycle coverage
8 states
Proposed through Retired with evidence and ownership at every stage
Fake SOC Alert
Source: Fictional Automation Governance Monitor • Time: 10:18
Fake Log Panel
[08:10] GOV-A901 review=MONTHLY owner=SECURITY_AUTOMATION_ENGINEER state=ACTIVE [08:32] GOV-A902 metric=ROUTING_ACCURACY current=94% target=95% action=CONTINUE_TUNE [08:54] GOV-A903 override_review=ENABLED recommendation_acceptance=78% state=ACTIVE [09:16] GOV-A904 approval_completeness=100% exception_allowed=NO state=HUMAN_GATED [09:38] GOV-A905 fallback_success=97% target=98% action=REVIEW [10:00] GOV-A906 routing_loop=DETECTED action=STOP_AUTOROUTING owner=SOC_WORKFLOW_OWNER [10:22] GOV-A907 evidence_completeness=99% closure_confirm=REQUIRED state=APPROVAL_GATED [10:44] GOV-A908 retired_version_usage=0 active_link_check=PASS state=MAINTENANCE
Training note: this is fake data for defensive analysis practice only.
Analyze the Evidence
Governance Health
Meaning: No current person or role is accountable for the automation outcome.
Governance response: Pause expansion and assign ownership before further change.
Meaning: The automation has not received its required governance review.
Governance response: Open review and consider temporary restrictions if dependencies changed.
Meaning: A temporary deviation reached its expiration without closure or renewal.
Governance response: Return to the normal rule, pause, or obtain new explicit approval.
Meaning: A defined quality, reliability, safety, or governance threshold has been crossed.
Governance response: Trigger the documented tune, investigate, pause, or disable decision.
Meaning: Automation requests broader access than the approved boundary.
Governance response: Require a material change review before activation.
Meaning: The automation is less explainable or auditable than before.
Governance response: Treat as a control issue and block affected transitions where required.
Meaning: A responsible team or approver has changed.
Governance response: Revalidate decision rights, access, exception ownership, and review cadence.
Meaning: The automation is being used for a different workflow or business reason.
Governance response: Reopen scope, risk, permission, human-boundary, and metric review.
Meaning: A newer workflow supersedes the old automation.
Governance response: Plan retirement, update references, preserve evidence, and close permissions conceptually.
Meaning: Human reviewers frequently correct the automation.
Governance response: Investigate whether logic, evidence, ownership, or business context has drifted.
Common Governance Mistakes
Why it fails: The person maintaining the automation is assumed to have authority to accept risk, approve business scope, and make high-impact decisions.
Better approach: Separate operational ownership from approval, control, risk, and business authority.
Why it fails: Temporary deviations become permanent without review.
Better approach: Require scope, compensating control, owner, expiration, and closure evidence.
Why it fails: Dashboards show threshold breaches but nobody is responsible for deciding what happens next.
Better approach: Assign metric ownership and explicit decision rules.
Why it fails: A permission, data source, or purpose changes but the automation remains 'approved' under the old design.
Better approach: Use material change triggers that reopen governance review.
Why it fails: Old automations and documentation remain active after replacement.
Better approach: Retire intentionally, block new use, preserve evidence, and update references.
Why it fails: Anyone who can click or configure a workflow is treated as authorized to approve the decision.
Better approach: Map decision rights explicitly.
Why it fails: Reviews happen only when something breaks.
Better approach: Use routine cadence plus event-driven triggers.
Why it fails: A workflow keeps running with no accountable maintainer or approver.
Better approach: Ownership change itself should trigger governance review.
Scenario Decision Lab
A fictional automation approved for read-only enrichment support now requests permission to update a workflow field. The technical owner says the new feature is small.
Scenario Decision Lab
A fictional automation has been operating under a temporary routing exception for fourteen days. The expiration date has arrived, but the owner has not submitted closure evidence or a renewal request.
Safe Fictional Lab
Build a fictional governance matrix that assigns ownership, authority, reviews, metrics, changes, exceptions, lifecycle states, and retirement responsibility across the A17 automation portfolio.
Create at least thirty-five fictional GOV-A records.
Give every record a stable GOV-A ID.
Link each record to relevant OPP, HITL, ENR, WFA, PRB, BND, FM, and VAL IDs.
Name the automation.
State the approved purpose.
Assign an Automation Owner.
Assign a Workflow Owner.
Assign a Control Owner.
Assign an Evidence Owner.
Assign a Platform Owner where relevant.
Assign an Authorized Approver where relevant.
Assign a Risk / Governance Owner.
Assign a Business / Service Owner where relevant.
Define decision authority.
Define disable authority.
Define re-enable authority.
Define exception authority.
Define retirement ownership.
Define routine review cadence.
Define event-driven review triggers.
Link key value metrics.
Link key failure metrics.
Define permission-review triggers.
Define purpose-change triggers.
Define data-source-change triggers.
Define ownership-change triggers.
Define evidence-health triggers.
Define threshold-breach decisions.
Define exception scope requirements.
Define compensating-control requirements.
Define exception expiration.
Define exception closure evidence.
Define lifecycle state.
Define transition criteria.
Define retirement criteria.
Include at least five Proposed-state records.
Include at least five Validated-state records.
Include at least ten Active-state records.
Include at least five Degraded or Paused-state records.
Include at least five Exception-state records.
Include at least five Retired-state records.
Include at least five permission-expansion reviews.
Include at least five expired-exception scenarios.
Include at least five ownership-transfer scenarios.
Include at least five metric-threshold governance decisions.
Include at least three examples where technical access does not equal decision authority.
Lab boundary
Use fictional organizations, owners, workflows, approvals, exceptions, and governance decisions only. Do not attempt to gain access to real systems, change real permissions, or bypass real approval processes. This lab is about safe governance design.
Analyze the Evidence
Advanced Challenge
Create a fictional organization-wide standard that defines who owns automation, who may approve what, when reviews occur, how exceptions work, and how automations are paused, re-enabled, or retired.
Purpose ownership
Workflow ownership
Control ownership
Evidence ownership
Platform ownership
Decision authority
Change-review authority
Permission-review authority
Risk acceptance
Exception approval
Exception expiration
Review cadence
Metric ownership
Threshold-to-decision mapping
Disable authority
Re-enable criteria
Ownership transfer
Lifecycle states
Retirement
Evidence archive
The strongest standard should make responsibility visible before a problem occurs, not only after.
Defender Habits
Skill Check
Check Your Understanding
Choose your answers first. Explanations appear only after submission.
Portfolio Prompt
Create the ninth artifact for your A17 Safe Automation Design and Governance Plan: a fictional Automation Governance Matrix with at least thirty-five records. Include GOV-A ID, linked OPP/HITL/ENR/WFA/PRB/BND/FM/VAL IDs, automation name, approved purpose, Automation Owner, Workflow Owner, Control Owner, Evidence Owner, Platform Owner where relevant, Authorized Approver, Risk/Governance Owner, Business/Service Owner where relevant, decision authority, disable authority, re-enable authority, exception authority, retirement owner, review cadence, event-driven triggers, key metrics, failure metrics, lifecycle state, transition criteria, exception controls, and retirement criteria.
Confidence / Readiness Reflection
A17.10 is the Security Automation Design Lab. Before continuing, make sure you can connect automation opportunity, human judgment, enrichment, ticketing, playbooks, scripting boundaries, failure handling, measurement, and governance into one defensible design.
I can assign distinct automation, workflow, control, evidence, platform, approval, and governance roles.
I can define decision rights for change, permission, exception, disable, re-enable, and retirement.
I can design lifecycle states and review triggers.
I can govern exceptions with scope, compensating controls, expiration, and closure evidence.
I can connect scorecard thresholds and failure signals to governance decisions.
Portfolio Build Guide
A technical maintainer, control owner, approver, and risk owner may all be different roles.
A reviewer should know exactly who may approve scope, permissions, exceptions, disabling, and retirement.
Automation should move through Proposed, Designed, Validated, Active, Degraded, Paused, Exception, and Retired states deliberately.
Permissions, purpose, ownership, evidence, metrics, and dependencies can all reopen governance review.
Every exception should have scope, owner, approver, expiration, compensating control, and closure evidence.
Threshold breaches should trigger a named person's decision rather than sit on a dashboard.
Old automations should not remain active simply because nobody turns them off.
A17.10 will combine all nine artifacts into the final Safe Automation Design and Governance Plan.
Key Takeaways
Lesson Safety Boundary
Do not attempt to change real permissions, bypass real approval processes, or access real operational systems. This lesson uses fictional governance records to teach ownership, authority, evidence, exceptions, reviews, lifecycle, and accountability.
Lesson Complete
You now have a practical model for ownership, decision rights, review cadence, change control, exceptions, metrics, disable and re-enable authority, lifecycle states, ownership transfer, and retirement. Next, A17.10 brings every A17 artifact together in the Security Automation Design Lab.