Overview
Change Monitoring and Detection is the ongoing process of logging, monitoring, and alerting on changes made to systems, infrastructure, and configurations to identify unauthorized or risky activity. It supports SOC 2 CC7.1 by ensuring system changes are detected promptly and reviewed by engineering.
Step-by-Step Process
Define monitored systems and changes
The Engineering Lead identifies which systems, cloud accounts, hosts, and applications are in scope for change monitoring, and what types of changes must be tracked (e.g., configuration, access, deployments). The output is a documented list of monitored assets and change types stored in the compliance repository.
Role: Engineering Lead
Enable change logging in monitoring tools
Engineering enables native logging and monitoring features in approved tools to capture system, configuration, and security-relevant changes. The output is active logging configurations that generate immutable logs.
Role: Engineering Lead
Configure alerts for critical changes
Engineering configures alerts for high-risk or unauthorized changes such as IAM updates, security group changes, or system file modifications. The output is alert rules that notify designated channels when changes occur.
Role: Engineering Lead
Review change alerts and logs
Engineering reviews alerts and change logs on an ongoing basis to identify unexpected or unauthorized changes. The output is documented review notes or ticket updates confirming whether changes were authorized.
Role: Engineering Lead
Investigate suspicious or unauthorized changes
When a suspicious change is detected, Engineering investigates the source, impact, and authorization status using logs and system records. The output is an investigation record and, if needed, an incident or remediation ticket.
Role: Engineering Lead
Document remediation actions
Engineering documents any remediation steps taken, such as reverting changes or updating configurations, and links them to the detected change. The output is a closed ticket or change record with timestamps.
Role: Engineering Lead
Retain change monitoring evidence
Engineering ensures logs, alerts, and review records are retained according to the log retention policy. The output is stored evidence available for audit review.
Role: Engineering Lead
What You Need Before Starting
- Approved list of production systems and cloud accounts
- Access to AWS, OSSEC, and Datadog administrative consoles
- Change management or ticketing system access
- Log retention and monitoring policy
Evidence Your Auditor Expects
- AWS CloudTrail event history export showing configuration changes with timestamps from the audit period
- Datadog alert configuration screenshot with creation date and monitored events
- OSSEC alert log file showing file integrity change with date and hostname
- Change investigation ticket with detection date, reviewer name, and resolution timestamp
How This Looks In Your Tools
AWS CloudTrail
Log in to the AWS Management Console and navigate to Services > CloudTrail > Trails. Confirm that at least one multi-region trail is enabled and that Management events are set to Read/Write. Verify the S3 bucket and optional CloudWatch Logs integration are configured.
To review changes, go to Services > CloudTrail > Event history and filter by Event source (e.g., iam.amazonaws.com, ec2.amazonaws.com) and Event name (e.g., CreateUser, AuthorizeSecurityGroupIngress). Use the time range selector to capture the audit period and export events as a CSV for evidence.
To configure alerts, navigate to Services > CloudWatch > Alarms > Create alarm and select the CloudTrail log metric filter for critical events. Configure notifications to an SNS topic connected to email or chat.
OSSEC
Log in to the OSSEC manager host and confirm agents are active by reviewing /var/ossec/bin/agent_control -lc. Ensure File Integrity Monitoring is enabled in /var/ossec/etc/ossec.conf for critical directories.
Review detected changes by accessing /var/ossec/logs/alerts/alerts.log and filtering for integrity check alerts (rule IDs 550–599). Capture entries showing file changes, user, and timestamp.
Configure alerting by editing ossec.conf to set appropriate alert levels and email notifications, then restart the OSSEC service using systemctl restart ossec.
Datadog
Log in to Datadog and navigate to Integrations > Integrations to confirm cloud, host, or Kubernetes integrations are enabled. Verify that system and audit logs are being ingested under Logs > Explorer.
Create monitors by navigating to Monitors > New Monitor and selecting Log or Infrastructure. Define queries for configuration changes or privileged actions and set thresholds and notification channels.
Review detected changes by filtering logs in Logs > Explorer by service, host, or change-related attributes, and export relevant log views with timestamps for audit evidence.
Common Audit Findings
- Change logging not enabled for all systems
- This occurs when new systems are deployed without being added to monitoring tools. Prevent it by requiring monitoring configuration as part of system provisioning checklists.
- Alerts configured but not reviewed
- Auditors find alerts exist but there is no evidence of review. Prevent this by documenting alert reviews in tickets or logs with reviewer names and dates.
- Insufficient retention of change logs
- Logs may be overwritten or deleted before the audit period is covered. Prevent this by enforcing retention settings that meet or exceed SOC 2 requirements.
- Unauthorized changes not investigated
- Changes are detected but no investigation or remediation is documented. Prevent this by linking alerts to investigation tickets and requiring closure notes.