When something significant changes, a new cloud provider, a major infrastructure migration, a new engineer with production access, a new regulation that applies to your business, you assess what that change means for your controls. Many companies have solid controls for their steady state but have gaps when the environment changes. This criterion asks whether your change management process includes a security impact assessment.
These are typical controls and implementation steps. Your systems and environment may differ.
Typical Control Security impact assessment as part of change management
Implementation Steps
Add a security impact field to your change management ticket template: what security controls does this change affect, and are new risks introduced that need to be added to the risk register?
Define which change categories trigger a mandatory risk review: new third-party vendors with data access, changes to authentication or access control architecture, migration to new cloud regions or providers, significant code releases affecting data handling
When the annual risk assessment occurs, review what significant changes happened during the year and confirm each was assessed for security impact
For new vendor relationships, the vendor onboarding process is the vehicle for change-triggered risk assessment, document this in your Vendor Risk Management Policy
Tools / Systems
Jira / Linear (change tickets with security impact field)Risk Assessment PolicyVendor Risk Management PolicyGRC platform (e.g., Vanta, Drata, your GRC platform, Scrut)
Typical Control Security impact assessment as part of change management
Evidence Artifacts
Change ticket template showing security impact assessment field
Sample change tickets from the audit period showing security impact was assessed for significant changes
Annual risk assessment document confirming change-triggered risks were reviewed
📅Per change ticket; annual risk assessment review of material changes
Cross-framework mappings coming in v1.1
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.
CC4.1
Selects, develops, and performs ongoing and separate evaluations
Monitoring Activities
6 evidence2 controls
CC4.2
Evaluates and communicates internal control deficiencies
Monitoring Activities
3 evidence1 control
CC5.1
Selects and develops control activities that mitigate risks
Control Activities
3 evidence1 control
CC5.2
Selects and develops general controls over technology
Control Activities
6 evidence2 controls
CC5.3
Deploys control activities through policies and procedures
Control Activities
3 evidence1 control
CC6.1
Logical access security infrastructure
Logical and Physical Access Controls
11 evidence3 controls
CC6.2
Registration and authorization prior to issuing credentials
Logical and Physical Access Controls
6 evidence2 controls
CC6.3
Role-based access management
Logical and Physical Access Controls
6 evidence2 controls
CC6.4
Physical access restrictions
Logical and Physical Access Controls
3 evidence1 control
CC6.5
Disposal and destruction of information assets
Logical and Physical Access Controls
3 evidence1 control
CC6.6
Controls against threats from outside system boundaries
Logical and Physical Access Controls
8 evidence2 controls
CC6.7
Restricts transmission and movement of information
Logical and Physical Access Controls
7 evidence2 controls
CC6.8
Controls to prevent or detect unauthorized software
Logical and Physical Access Controls
6 evidence2 controls
CC7.1
Detection and monitoring for vulnerabilities
System Operations
8 evidence2 controls
CC7.2
Monitoring for anomalies and security events
System Operations
4 evidence1 control
CC7.3
Evaluation of security events as security incidents
System Operations
4 evidence1 control
CC7.4
Incident response program
System Operations
4 evidence1 control
CC7.5
Recovery from security incidents
System Operations
4 evidence1 control
CC8.1
Authorized change management process
Change Management
8 evidence2 controls
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
Security impact assessment as part of change management
Implementation steps
Include a security impact question on the work order template for all infrastructure changes: 'Does this change affect any security controls? If yes, describe the impact and any new risks.'
For significant changes (new server added to production, firewall rule changes, new third-party software installed), require a management sign-off that includes acknowledgement of security impact
At the annual risk assessment, review the change log for the year and confirm significant changes were assessed
Tools / systems
Work order system (change tickets)
Risk Assessment Policy
Annual risk assessment process
GRC platform (e.g., Vanta, Drata, your GRC platform, Scrut)
Evidence artifacts
Work order template with security impact field
Sample work orders for significant infrastructure changes showing security impact was assessed
Annual risk assessment confirming material changes were reviewed for security implications
Evidence frequency: Per significant change; annual review confirmation
