Change Management Standards Analysis
Date: 2026-02-11
Author: Claude (Opus 4.6)
Project: PILOT
Purpose: Research global change management standards applicable to CODITECT platform, both for internal compliance and customer-facing capabilities. Foundation for ADR-176.
1. Executive Summary
CODITECT operates as both a consumer and provider of change management: it must comply with change management standards internally (code, infrastructure, AI model changes) AND provide change management capabilities to its customers (component migration, configuration control, audit trails). This dual role requires a comprehensive framework that maps to recognized global standards.
Key finding: ADR-175 (Component Migration Process) established an excellent foundation aligning with ISO 10007, NIST SP 800-128, and ITIL v4 — but only for one change type (component relocation). CODITECT has 10+ distinct change types that need unified governance. ADR-176 will establish that unified framework.
2. Change Types in CODITECT
| # | Change Type | Current Governance | Gap Level |
|---|
| 1 | Code changes (PRs, commits, branches) | Git workflow, code review | LOW - well-established |
| 2 | Component migration (cross-repo relocation) | ADR-175 | NONE - fully governed |
| 3 | Configuration changes (feature flags, env vars) | Ad-hoc | HIGH |
| 4 | Infrastructure changes (IaC, K8s, Terraform) | Cloud deployment scripts | MEDIUM |
| 5 | Database/schema changes (migrations) | Django migrations | LOW |
| 6 | AI/ML model changes (prompts, agent configs, model selection) | Agent versioning | HIGH |
| 7 | Framework component changes (skills, agents, hooks, commands) | ADR-049 lifecycle | MEDIUM |
| 8 | Customer-facing API changes (versioning, deprecation) | Planned (N track) | HIGH |
| 9 | Documentation changes (docs-as-code) | PR review | LOW |
| 10 | Security changes (patches, vulnerability remediation) | Security scanning | MEDIUM |
| 11 | Organizational process changes (workflows, policies) | Session logs | HIGH |
| 12 | Registry/metadata changes (component-counts, activation status) | Auto-hooks | LOW |
3. Standards Matrix
3.1 NIST Standards
NIST SP 800-128 — Guide for Security-Focused Configuration Management
- Version: Update 1 (October 2019)
- Scope: Security-focused configuration management (SecCM) for information systems
- Key Requirements:
- CM Planning: Establish CM policies, procedures, and responsibilities
- Configuration Identification: Baseline configurations for all system components
- Configuration Change Control: Formal process for requesting, evaluating, approving changes
- Configuration Status Accounting: Record and report current configuration status
- Configuration Verification and Audit: Verify actual matches approved baseline
- CODITECT Mapping:
- CM Planning: CLAUDE.md directives + ADR governance
- Identification:
component-counts.json, framework-registry.json, component-activation-status.json
- Change Control: Git PR workflow + ADR approval gates (ADR-175 Step 7)
- Status Accounting: Session logs, trajectory dashboard,
/cxq --stats
- Verification: Hooks (task-id-validator, component-indexer), MoE judges
- Gap: No formal CM Plan document; SecCM roles not explicitly defined
NIST SP 800-53 Rev 5 — Security and Privacy Controls (CM Family)
- Version: Revision 5, Update 1 (December 2024)
- Key Controls:
| Control | Title | CODITECT Status |
|---|
| CM-1 | Policy and Procedures | Partial (CLAUDE.md, ADRs) |
| CM-2 | Baseline Configuration | Yes (registries, component-counts) |
| CM-3 | Configuration Change Control | Partial (Git + ADR-175 for migration) |
| CM-4 | Impact Analyses | Yes (MCP impact analysis tool) |
| CM-5 | Access Restrictions for Change | Partial (Git branch protection) |
| CM-6 | Configuration Settings | Partial (env vars, no centralized) |
| CM-7 | Least Functionality | Not addressed |
| CM-8 | System Component Inventory | Yes (component-indexer, platform.db) |
| CM-9 | Configuration Management Plan | Not formalized |
| CM-10 | Software Usage Restrictions | Not addressed |
| CM-11 | User-installed Software | N/A (SaaS) |
| CM-12 | Information Location | Partial (ADR-118 databases) |
| CM-13 | Data Action Mapping | Not addressed |
| CM-14 | Signed Components | Planned (code-signing-specialist agent) |
- Key Enhancements for CM-3:
- CM-3(1): Automated Documentation, Notification, and Prohibition of Changes
- CM-3(2): Testing, Validation, and Documentation of Changes
- CM-3(4): Automated Security Response
- CM-3(5): Automated Change Implementation
- CM-3(6): Cryptography Management
- CM-3(7): Review System Changes
- CM-3(8): Prevent or Restrict Configuration Changes
NIST CSF 2.0 — Cybersecurity Framework (February 2024)
- Version: 2.0 (Released February 26, 2024)
- Key change management categories:
- GV (Govern): New core function — elevates cybersecurity to strategic enterprise risk
- GV.OC: Organizational Context — understand change management context
- GV.RM: Risk Management Strategy — change risk assessment
- GV.RR: Roles, Responsibilities, and Authorities — change approval authorities
- PR.IP: Information Protection Processes — configuration change control
- PR.DS: Data Security — protect integrity of data during changes
- ID.AM: Asset Management — maintain inventory through changes
- RC.RP: Recovery Planning — rollback capabilities
- CODITECT Gap: GOVERN function not fully mapped; need explicit cyber governance for changes
NIST SP 800-37 Rev 2 — Risk Management Framework
- Version: Revision 2 (December 2018)
- Change Management Integration:
- Prepare Step: Establish organizational context for change management
- Monitor Step: Continuous monitoring of system changes including:
- Assessing control effectiveness after changes
- Documenting changes to system or environment
- Conducting risk assessments and impact analyses
- Reporting security/privacy status
- CODITECT Mapping: Impact analysis MCP tools align; need formal RMF integration
NIST AI RMF 1.0 — AI Risk Management Framework
- Version: 1.0 (January 2023) + Generative AI Profile (NIST-AI-600-1, July 2024)
- 2025 Updates: Continuous improvement cycle, not compliance checkbox
- Key Requirements for AI Change Management:
- GOVERN: AI governance structures, policies, processes for change
- MAP: Context and dependencies mapping before changes
- MEASURE: Metrics for AI system changes (drift, performance)
- MANAGE: Risk treatment for AI changes, including rollback
- Model provenance and data integrity tracking
- Third-party model assessment for external AI components
- Continuous monitoring (AI systems evolve post-deployment)
- CODITECT Gap: No formal AI change management process; agent/prompt changes unversioned; model selection changes not tracked
NIST SP 800-204C/D — DevSecOps for Microservices
- Relevance: CI/CD pipeline change management, supply chain security
- Key guidance: Integration of security into delivery pipelines, change verification
NIST SP 800-218r1 (SSDF v1.2) — Secure Software Development Framework
- Status: Initial Public Draft (December 2025), comments through January 2026
- Key update: Emphasis on continuous, provable secure development practices
- Relevance: Change management for secure development lifecycle
3.2 ISO Standards
ISO 10007:2017 — Quality Management: Guidelines for Configuration Management
- 5 Activities: Planning, Identification, Change Control, Status Accounting, Verification/Audit
- CODITECT Alignment (from ADR-175):
| Activity | ADR-175 Implementation |
|---|
| Planning | Workflow definition (component-migration.yaml) |
| Identification | Component discovery (Step 2), manifest (Step 3) |
| Change Control | Approval gates (Steps 4, 7, 11) |
| Status Accounting | Registry updates (Step 8), audit log (Step 10) |
| Verification/Audit | Verification (Step 9), completion report (Step 12) |
- Gap: Only applied to component migration; needs extension to all change types
ISO/IEC 20000-1:2018 — IT Service Management
- Change Management Process Requirements:
- Documented change management policy
- Change classification and assessment
- Approval authorities defined
- Change scheduling and coordination
- Post-implementation review
- Emergency change procedures
- CODITECT Gap: No formal change management policy document; no emergency change procedures
- Annex A Controls:
- A.8.32 Change management: Changes to information processing facilities and systems shall be subject to change management procedures
- A.5.22 Monitoring, review and change management of supplier services: Changes to supplier services shall be managed
- A.8.9 Configuration management: Configurations including security configurations shall be established, documented, implemented, monitored and reviewed
- CODITECT Gap: No formal ISMS change management procedure
ISO 9001:2015 — Quality Management Systems
- Clause 6.3 (Planning of Changes): Changes shall be carried out in a planned manner, considering: purpose, consequences, integrity, availability of resources, allocation of responsibilities
- CODITECT Mapping: Track-based planning (ADR-116) partially addresses this
- 8.32 Change Management: Detailed guidance on implementing change management controls
- Policy and procedures for change management
- Change impact assessment
- Risk assessment for changes
- Formal approval process
- Communication of changes to stakeholders
- Rollback procedures
- Documentation and audit trails
ISO 42001 — AI Management System Standard
- Published: 2023
- Change Management for AI:
- Lifecycle management for AI systems
- Impact assessment for AI changes
- Documentation of AI system changes
- Monitoring and reviewing AI system performance
- Risk treatment for AI-specific risks
- CODITECT Gap: No AI-specific change management; critical for a platform with 150+ AI agents
ISO/IEC 12207:2017 — Software Lifecycle Processes
- Configuration Management Process:
- Configuration item identification
- Configuration control (change management)
- Configuration status accounting
- Configuration evaluation
- Release management
- Overlap with ISO 10007: Strong alignment but software-specific
3.3 ITIL v4 Practices
- Purpose: Maximize successful IT changes while managing risk
- Change Types:
| Type | Risk Level | Approval | CODITECT Mapping |
|---|
| Standard | Low, pre-authorized | Pre-approved | Component updates, doc changes |
| Normal | Medium, requires assessment | CAB or delegated | Infrastructure changes, API changes |
| Emergency | High, urgent | ECAB (expedited) | Security patches, production fixes |
- Key Concepts:
- Change Authority: Who approves what level of change
- Change Schedule: Planned change windows
- Change Model: Repeatable steps for standard changes
- Post-Implementation Review (PIR)
- CODITECT Gap: No change classification model; no defined change authorities; no formal PIR process
Release Management
- Purpose: Plan, schedule, control deployment of changes
- CODITECT Mapping: Bottom-up commit workflow (ADR-175), but only for migrations
Service Configuration Management
- Purpose: Maintain accurate configuration information
- CODITECT Mapping: platform.db, framework-registry.json, component-activation-status.json
Deployment Management
- Purpose: Move new or changed components to live environments
- CODITECT Mapping: Cloud deployment (coditect-cloud-infra), submodule sync
3.4 Additional Frameworks
COBIT 2019
- BAI06 (Manage Changes): Formal change management process, impact assessment, authorization, implementation, testing, post-implementation review
- BAI07 (Manage Change Acceptance and Transitioning): Acceptance testing, release management, go-live support
TOGAF — Architecture Change Management
- Simplicity of change: Standard changes for isolated items; incremental for existing architecture; re-architecting for transformational changes
- CODITECT Mapping: ADR process serves as architecture change management
SAFe — Change Management in Scaled Agile
- Continuous delivery pipeline: Build → test → stage → deploy
- Feature toggles as change management
- Inspect & Adapt events for process changes
3.5 Regulatory Requirements
| Regulation | Change Management Requirement | CODITECT Relevance |
|---|
| SOC 2 Type II | CC6.1, CC8.1: Change management controls, testing, approval | Customer-facing compliance |
| FedRAMP | CM controls from NIST 800-53 (CM-1 through CM-14) | Federal customers |
| HIPAA | 164.312(e): Technical safeguards for changes to ePHI systems | Healthcare customers |
| PCI DSS v4.0 | Requirement 6: Change management for payment systems | Payment-handling customers |
| GDPR | Article 25: Data protection by design during changes | EU customers/operations |
| SOX | IT general controls: Change management for financial systems | Public company customers |
| ISO 27001 | Annex A.8.32: CM procedures | Certification-seeking customers |
4. Existing CODITECT ADR Coverage Map
4.1 ADRs with Change Management Relevance
| ADR | Title | Change Types Covered | Standards Referenced | Gap |
|---|
| ADR-175 | Component Migration Process | Component relocation | ISO 10007, NIST 800-128, NIST CSF 2.0, ITIL v4 | Only migration; no other change types |
| ADR-049 | Component Creation Lifecycle | Component creation, registration, activation | None explicitly | No change/update lifecycle; only creation |
| ADR-119 | Lowercase Naming Migration | Naming convention changes | None | One-time migration, not reusable process |
| ADR-054 | Track Nomenclature | Task tracking changes | None | Tracks changes but doesn't govern them |
| ADR-116 | Track-Based Plan Architecture | Planning changes | None | Plan structure, not change control |
| ADR-118 | Four-Tier Database Architecture | Database schema changes | None | Architecture, not change process |
| ADR-160 | Inter-Session Messaging | Session coordination | None | Communication, not change governance |
| ADR-161 | Component QA Framework | Quality changes | None | Quality gates, not change authorization |
| ADR-162 | Progressive Component Disclosure | Visibility changes | None | Progressive access, not change control |
| ADR-173 | Structured Inter-Session Message Schema | Conflict detection (change coordination) | None | Detects conflicts but doesn't prevent them |
| ADR-047 | Platform Foundation | Platform architecture changes | None | Foundation, not change process |
| ADR-146 | Unified Task ID Strategy | Task tracking | None | Identification only |
4.2 Existing Components
| Component | Type | Change Management Role |
|---|
agents/change-management.md | Agent | Thin stub; ITIL change management for IT |
skills/implementing-compliance/SKILL.md | Skill | SOC2/GDPR/HIPAA compliance implementation |
hooks/task-id-validator.py | Hook | Enforces task ID on all changes |
hooks/component-indexer-hook.py | Hook | Auto-indexes after component changes |
scripts/component-migration.py | Script | ADR-175 migration engine |
workflows/component-migration.yaml | Workflow | ADR-175 migration workflow |
| MCP impact-analysis tools | MCP | Change impact analysis |
| MCP call-graph tools | MCP | Blast radius for code changes |
5. Gap Analysis Summary
5.1 Critical Gaps (Must address in ADR-176)
| Gap | Impact | Standard Requiring It |
|---|
| No unified change management policy | Cannot demonstrate compliance | ISO 20000, ISO 27001, SOC 2, NIST CM-1 |
| No change classification model | All changes treated equally | ITIL v4, ISO 20000 |
| No defined change authorities | Unclear who approves what | ITIL v4, NIST CM-5, ISO 27001 A.8.32 |
| No AI/ML change management | Agent/model changes ungoveerned | ISO 42001, NIST AI RMF |
| No emergency change procedure | Emergency changes uncontrolled | ITIL v4, ISO 20000 |
| No configuration change tracking (feature flags, env vars) | Config drift undetectable | NIST CM-6, ISO 27002 8.32 |
| No formal CM Plan | Cannot demonstrate CM program | NIST CM-9, ISO 10007 |
| No post-implementation review | No learning from changes | ITIL v4, COBIT BAI06 |
5.2 Medium Gaps
| Gap | Impact | Standard Requiring It |
|---|
| No change scheduling/windows | Changes at any time | ITIL v4 |
| No change failure rate tracking | No DORA metric | Industry best practice |
| No customer-facing change notification | Customers surprised by changes | ISO 20000, SLA |
| No rollback verification | Rollback may not work | NIST CSF RC.RP |
| Infrastructure change not governed | IaC changes ad-hoc | NIST CM-3, SOC 2 |
5.3 What's Already Strong
| Capability | Standard Alignment |
|---|
| Component inventory (platform.db) | NIST CM-8, ISO 10007 |
| Audit trail (session logs, commit history) | NIST CM-3, ISO 27001 |
| Impact analysis (MCP tools) | NIST CM-4 |
| Baseline configuration (registries) | NIST CM-2 |
| Component migration process (ADR-175) | ISO 10007, NIST 800-128, ITIL v4 |
| Task tracking (track nomenclature) | NIST CM-3 documentation |
6. Recommendations for ADR-176
6.1 Scope
ADR-176 should establish a Comprehensive Change Management Framework that:
- Defines change types and classification model (Standard/Normal/Emergency per ITIL)
- Maps change authorities for each type and risk level
- Establishes change process for each of the 12 change types
- Provides AI/ML-specific change management (ISO 42001, NIST AI RMF)
- Enables CODITECT to offer change management as a customer capability
- Creates compliance mappings customers can reference for their audits
6.2 Architecture Decision
Decision: Adopt ITIL v4 Change Enablement as the primary model, enriched with NIST 800-53 CM controls and ISO 10007 configuration management activities.
Rationale:
- ITIL v4 provides the most practical classification model (Standard/Normal/Emergency)
- NIST 800-53 provides the most comprehensive control set (CM-1 through CM-14)
- ISO 10007 provides the 5-activity framework ADR-175 already aligns with
- This combination covers regulatory requirements (SOC 2, FedRAMP, ISO 27001)
6.3 Change Classification Model
| Classification | Risk | Examples | Approval | CODITECT Implementation |
|---|
| Standard | Pre-assessed, low risk | Doc updates, component metadata, style changes | Auto-approved via hooks | Existing hook system |
| Normal | Medium, needs assessment | Feature PRs, infrastructure changes, new agents, API changes | PR review + designated approver | Git PR + ADR if architectural |
| Major | High, cross-system impact | Database migrations, breaking API changes, framework changes | ADR + human approval | ADR process + approval gate |
| Emergency | Critical, time-sensitive | Security patches, production fixes, data breach response | Fast-track with post-review | New: Emergency Change Process |
| AI/ML | Variable, requires AI-specific assessment | Model changes, prompt engineering, agent behavior changes | AI Change Board review | New: AI Change Assessment |
6.4 Customer-Facing Capabilities
CODITECT should provide customers with:
- Change Management Workflow Engine — Configurable approval workflows per change type
- Change Impact Analysis — Leveraging MCP tools for customer codebases
- Compliance Evidence Collection — Auto-generated audit trails for SOC 2, ISO 27001
- Change Calendar — Visibility into planned changes
- Change Analytics — DORA metrics (change failure rate, lead time, deployment frequency)
7. Standards Cross-Reference Matrix
| Requirement | NIST 800-53 | NIST 800-128 | NIST CSF 2.0 | ISO 10007 | ISO 27001 | ITIL v4 | SOC 2 |
|---|
| Change policy | CM-1 | SecCM Plan | GV.PO | Planning | A.5.1 | Policy | CC1.1 |
| Baseline config | CM-2 | Baseline | PR.IP | Identification | A.8.9 | SCM | CC6.1 |
| Change control | CM-3 | Change Control | PR.IP | Change Control | A.8.32 | Change Enablement | CC8.1 |
| Impact analysis | CM-4 | - | ID.RA | - | A.8.32 | Change assessment | CC3.2 |
| Access restriction | CM-5 | - | PR.AC | - | A.8.3 | - | CC6.1 |
| Config settings | CM-6 | - | PR.IP | - | A.8.9 | SCM | CC6.1 |
| Component inventory | CM-8 | - | ID.AM | Identification | A.5.9 | SCM | CC6.1 |
| CM Plan | CM-9 | SecCM Plan | GV.PO | Planning | A.5.1 | - | CC1.1 |
| Signed components | CM-14 | - | PR.DS | - | - | - | CC6.1 |
| Status accounting | - | Status Acct. | - | Status Acct. | - | SCM | - |
| Verification/audit | - | Verify/Audit | DE.CM | Verify/Audit | A.8.34 | - | CC4.1 |
| Emergency changes | - | - | RS.RP | - | - | Emergency | CC8.1 |
| Post-review | - | - | - | - | - | PIR | CC4.1 |
8. Sources
NIST Publications
ISO Standards
- ISO 10007:2017 — Quality Management: Configuration Management Guidelines
- ISO/IEC 20000-1:2018 — IT Service Management
- ISO 27001:2022 — Information Security Management Systems
- ISO/IEC 27002:2022 — Information Security Controls
- ISO 9001:2015 — Quality Management Systems
- ISO 42001:2023 — AI Management System
- ISO/IEC 12207:2017 — Software Lifecycle Processes
ITIL and Industry
- ITIL v4 Foundation — Change Enablement Practice
- COBIT 2019 — BAI06 Manage Changes, BAI07 Manage Change Acceptance
- TOGAF — Architecture Change Management
Regulatory
- SOC 2 Type II — Trust Services Criteria (CC6.1, CC8.1)
- FedRAMP — NIST 800-53 CM controls overlay
- PCI DSS v4.0 — Requirement 6
- HIPAA — 164.312(e) Technical Safeguards
- GDPR — Article 25 Data Protection by Design
Analysis Document: change-management-standards-analysis-2026-02-11.md
Full Path: internal/analysis/change-management/change-management-standards-analysis-2026-02-11.md
Next Step: ADR-176 — Comprehensive Change Management Framework