The entity authorizes, designs, develops or acquires, configures, documents, tests, approves, and implements changes to infrastructure, data, software, and procedures to meet its objectives.
Every change to production, code deployments, infrastructure modifications, configuration updates, database migrations, follows a documented, approved process before it touches production. The change management lifecycle covers design, build, test, approve, deploy. Auditors will sample specific changes and trace them back to an approved ticket; changes deployed without an approval are findings.
These are typical controls and implementation steps. Your systems and environment may differ.
Typical Control Code change review and approval via pull request workflow
Implementation Steps
Enforce branch protection on the main/production branch in GitHub or GitLab: require at least one independent reviewer approval before any merge, and block direct pushes
Require a linked Jira ticket on every pull request, the ticket documents the business reason for the change and any testing notes
Configure CI/CD pipeline (GitHub Actions, GitLab CI) to run automated tests, SAST scans, SCA (software composition analysis) for dependency vulnerabilities, and secret detection on every PR; a failing pipeline blocks merge
Maintain a deployment log: every production deployment records the PR number, approver, deployment time, and whether rollback was triggered, GitHub Actions deployment history satisfies this
Typical Control Segregated environments with no production data in development
Implementation Steps
Maintain separate AWS accounts (or Azure subscriptions) for development, staging, and production, account-level separation is harder to accidentally bridge than environment-level within one account
Block all IAM roles and credentials from having cross-environment write access; production credentials must not be accessible from developer laptops or CI runners without explicit, logged assumption
Prohibit production database copying to development environments; if debugging requires production-like data, use a data anonymization pipeline to generate synthetic data
Document environment segregation in the Secure Development Policy; auditors will look for whether this is a documented requirement, not just an unwritten convention
When we add ISO 42001 and ISO 27001, you'll see which controls map to this criterion.
ISO
ISO 42001
AI Management Systems
ISO
ISO 27001
Information Security
Mapping data will appear here automatically when the frameworks are published.
CC9.1
Risk mitigation for business disruptions
Risk Mitigation
4 evidence1 control
CC9.2
Vendor and business partner risk management
Risk Mitigation
4 evidence1 control
Help us build what matters.
Vote for the next framework, subscribe for updates, and let us know if you'd contribute.
What should we add next?
Vote for the framework you need most.
0
ISO 42001
0
ISO 27001
0
CMMC
0
CPCSC
Stay Updated
Get notified when new frameworks and features are added.
On-premises implementation and evidence
Code change review and approval via pull request workflow
Implementation steps
Use a Git repository (self-hosted Gitea or GitHub) for all application code and infrastructure configuration; enforce PR-based merges with required review from at least one person other than the author
For infrastructure changes that cannot go through Git (e.g., firewall rule changes), create a change request in the ticketing system with: description of the change, risk assessment, test plan, and approver sign-off before implementation
Maintain a Change Log: a dated record of all changes to production systems during the audit period, with the change request reference, approver, and outcome
For ISM self-approval (common in small teams): document the policy exception clearly, the Change Management Policy should state that the ISM's approval constitutes management approval for normal changes
Tools / systems
Gitea / GitHub (source control)
Ansible (infrastructure-as-code changes)
Firewall appliance (rule audit log)
Evidence artifacts
Git repository screenshot showing branch protection rules and PR merge history
Sample change request ticket: description, risk, approver, and deployment confirmation
Change Log for the audit period listing production changes with dates, requestors, and approvers
Firewall audit log showing rule changes with timestamps (auditors may sample a specific change and trace it to an approved ticket)
Segregated environments with no production data in development
Implementation steps
Physically or logically separate production and non-production environments; at minimum, production must be on a separate VLAN with firewall rules blocking developer workstations from accessing production servers directly
Maintain separate credentials for production vs. development; developer accounts should have no standing access to production systems
Document the prohibition on production data in development in the Configuration and Asset Management Policy; if a production data copy is ever needed for debugging, require a documented exception ticket with management approval and data disposal confirmation after use
Verify segregation annually: run an access review confirming no developer accounts have production server access
Tools / systems
Firewall appliance (VLAN enforcement)
Active Directory (separate OUs for prod/dev accounts)
Wazuh (log collection/HIDS) (access monitoring)
Evidence artifacts
Network diagram showing production and development VLANs are separated with firewall rules
Active Directory or credential store showing separate accounts for production vs. development access
Policy document (Configuration and Asset Management Policy or Secure Development Policy) stating the production data prohibition
Annual access review output confirming no developer accounts have production access
