CIS AWS Foundations v1.2 3.14: Ensure a log metric filter and alarm exist for VPC changes

To meet cis aws foundations v1.2 3.14: ensure a log metric filter and alarm exist for vpc changes requirement, you must (1) log VPC-related API activity to CloudWatch Logs via CloudTrail, (2) create a CloudWatch Logs metric filter that matches VPC change events, and (3) alarm on that metric so your team gets notified and can investigate quickly. ¹

Key takeaways:

• You need both detection (metric filter) and response trigger (alarm) for VPC changes, not just CloudTrail logging. ¹
• The control fails in audits when CloudTrail isn’t delivering to the log group the filter queries, or when alarms notify nobody. ²
• Evidence is simple but specific: filter pattern, alarm configuration, notification target, and proof the pipeline works end-to-end. ¹

VPC changes are “control plane” events that can materially alter network exposure: routes can be redirected, security groups can be opened, network ACLs can be loosened, and gateways or peering links can be created to move traffic in unexpected ways. CIS AWS Foundations v1.2 3.14 focuses on early detection of those changes by requiring a CloudWatch Logs metric filter and a CloudWatch alarm tied to VPC change events. ³

For a Compliance Officer, CCO, or GRC lead, the fastest path is to treat this as an end-to-end detection control with four moving parts: (1) CloudTrail records the relevant API calls, (2) CloudTrail delivers events into a CloudWatch Logs log group, (3) a metric filter matches VPC change activity in that log group, and (4) an alarm notifies the right responders through an owned channel (SNS topic integrated to email, ticketing, or on-call tooling). ²

Operationalizing this requirement means writing down ownership (who responds), tuning scope (which accounts/regions), and retaining evidence that a test event triggers an alert. That’s what auditors and internal assurance teams consistently want to see for this class of CIS controls. ¹

Regulatory text

Requirement (excerpt): “Implement CIS AWS Foundations Benchmark v1.2 requirement 3.14 as mapped in AWS Security Hub.” ¹

What that means for an operator: You must implement the AWS Security Hub mapping for CIS 3.14 (mapped control: CloudWatch.14) by configuring CloudWatch Logs to detect VPC-related API changes from CloudTrail, then alarming on those detections. The minimum bar is: a metric filter exists for the right log group, the filter matches VPC change events, an alarm exists on the produced metric, and the alarm notifies a monitored destination. ²

Plain-English interpretation

You are required to detect and alert when someone changes VPC networking configuration in AWS. Logging alone is not enough; CIS expects a mechanism that converts relevant log events into a measurable signal (metric) and then alerts responders (alarm). ³

Think of this requirement as: “If networking changes, someone should know quickly, and the organization should be able to prove it.”

Who it applies to

Entity scope: Any team operating AWS accounts where VPCs exist, including shared services, platform engineering, infrastructure, security operations, and application teams with delegated network permissions. ³

Operational context where it matters most:

• Multi-account AWS Organizations with centralized networking and distributed app teams.
• Environments with frequent IaC deployments (CloudFormation/Terraform/CDK) that modify routes, subnets, gateways, security groups, or NACLs.
• Regulated workloads where network segmentation is a core control objective. ³

What is “in scope” for VPC changes (practical view):

• VPC creation/deletion and attribute updates
• Subnet creation/deletion
• Route table and route changes
• Internet/NAT gateway changes
• VPC peering and attachments
• Security group and network ACL changes
  Your metric filter should cover the relevant API calls your organization considers “network perimeter changes,” aligned to the CIS mapping expectation. ²

What you actually need to do (step-by-step)

Step 1: Confirm CloudTrail is capturing management events and delivering to CloudWatch Logs

1. Identify your organization’s trail strategy: single org trail, per-account trails, or hybrid.
2. Verify management events are enabled for the trail(s).
3. Verify CloudTrail delivers events to a CloudWatch Logs log group (not only S3), because metric filters run against CloudWatch Logs.
   Operator check: If the trail does not send to CloudWatch Logs, your metric filter will never see events and the control will fail in practice and in audits. ²

Evidence to capture now: screenshots or exports showing trail configuration and the target log group name/ARN.

Step 2: Create (or standardize) the CloudWatch Logs metric filter for VPC changes

1. Select the log group receiving CloudTrail events.
2. Create a metric filter that matches VPC change API activity.
3. Define:
   • Filter pattern (the “match logic”)
   • Metric namespace (e.g., CIS/AWS)
   • Metric name (e.g., VPCChanges)
   • Metric value (commonly 1 per match)

Implementation tip: Standardize the namespace/metric names across accounts so your dashboards, alarms, and evidence collection are consistent.

Evidence to capture: metric filter JSON/config, filter pattern text, and the log group association.

Step 3: Create a CloudWatch alarm on the metric

1. Create an alarm on the VPCChanges (or equivalent) metric.
2. Alarm settings to decide explicitly:
   • Threshold logic (alarm on any occurrence vs. multiple occurrences)
   • Evaluation period and datapoints to alarm
   • Missing data treatment (don’t mask failures where no data arrives)
3. Add an alarm action to an SNS topic owned by security operations or the cloud platform team.

Audit-critical detail: An alarm that exists but notifies an unmonitored email address, a decommissioned SNS topic, or a sandbox paging integration is a common reason the control is treated as ineffective.

Evidence to capture: alarm configuration, actions list, and SNS topic subscription list.

Step 4: Route notifications into an owned response workflow

1. Decide the responder: SecOps, cloud infrastructure on-call, or network engineering.
2. Decide the workflow: ticket creation, chat alert, paging, or email distribution list tied to on-call rotation.
3. Document the minimum triage steps:
   • Identify API caller (principal)
   • Identify changed resource (VPC/subnet/route table/security group)
   • Confirm change was authorized (change ticket/IaC pipeline)
   • Roll back or mitigate if unauthorized

Control owner: Name a team and a role (not a person) in your control narrative.

Step 5: Test end-to-end and record proof

1. Perform a controlled VPC change in a non-production account (for example, create a test security group rule or a test route table change).
2. Verify:
   • CloudTrail event appears in the CloudWatch Logs log group.
   • Metric increments.
   • Alarm transitions to ALARM state.
   • Notification lands in the intended channel.
3. Save test artifacts (timestamp, event ID, alarm state change history).

This test evidence is often what separates “configured” from “operating effectively.” ³

Required evidence and artifacts to retain

Keep evidence that shows design, implementation, and operation:

Configuration evidence (design/implementation)

• CloudTrail configuration showing delivery to CloudWatch Logs log group (name/ARN). ²
• CloudWatch Logs metric filter configuration (pattern, metric namespace/name, associated log group). ²
• CloudWatch alarm configuration (metric, threshold, evaluation settings, actions). ²
• SNS topic and subscriptions (who receives alerts).

Operational evidence (effectiveness)

• Alarm history (state transitions and notifications).
• A sample alert/ticket (redacted) showing triage fields populated.
• A test record proving an induced VPC change generated an alert.

Governance evidence (ownership)

• Control narrative/runbook: owner, response SLA target (internal), and escalation path.
• Change management linkage: how authorized changes are distinguished (IaC pipeline identity, ticket numbers, approvals).

Common exam/audit questions and hangups

Use these as your readiness checklist:

1. “Which log group does the metric filter read from?” Auditors will trace CloudTrail → log group → metric filter. Missing linkage is a frequent hangup. ²
2. “What VPC changes are covered by the filter pattern?” Expect scrutiny on whether you detect the meaningful network perimeter changes. ³
3. “Who receives the alarm and what do they do?” They will ask for a runbook and evidence of monitoring.
4. “How do you prevent alert fatigue?” You should show routing, severity labeling, and tuning decisions.
5. “How do you handle multi-account and multi-region?” They’ll ask whether the control is deployed consistently across the fleet.

Frequent implementation mistakes and how to avoid them

Mistake	Why it fails	How to avoid
CloudTrail logs to S3 only	Metric filter can’t see events	Enable CloudTrail delivery to CloudWatch Logs for the trail feeding this control. 2
Filter pattern too narrow	Misses real VPC changes	Align pattern coverage to the CIS mapping intent; validate against real change types your teams perform. 3
Alarm exists but actions are empty	No one is notified	Require SNS action in IaC and add subscription verification as a control step.
Alarm not deployed to all accounts/regions	Gaps in detection	Standardize via org-level automation (IaC, StackSets, or account vending pipelines).
Notifications route to individuals	Breaks on role changes	Route to team-owned SNS topics integrated to on-call and ticketing.
No evidence of testing	Control can be “paper only”	Run and store periodic end-to-end test results and alarm histories.

Enforcement context and risk implications

No public enforcement cases were provided in the supplied sources for this specific CIS requirement, so don’t treat CIS 3.14 as a standalone legal mandate. Treat it as a defensible security baseline used in audits, customer security reviews, and internal risk governance. ³

Risk impact is straightforward: undetected VPC changes can introduce unintended internet exposure, break segmentation assumptions, or create covert paths for data movement. This control reduces dwell time by generating an actionable signal for investigation soon after the change occurs. ³

Practical 30/60/90-day execution plan

First 30 days (stabilize the baseline)

• Inventory AWS accounts and identify where CloudTrail events land (CloudWatch Logs vs. S3). ²
• Pick a standard: log group naming, metric namespace, alarm naming, SNS topic ownership.
• Implement the metric filter + alarm in a pilot set of accounts.
• Write a one-page runbook: triage steps, ownership, and escalation.

Days 31–60 (scale and harden)

• Roll out across all in-scope accounts and regions via IaC.
• Centralize alert intake (SNS → ticketing/on-call) and validate subscriptions.
• Add tuning: exclude known automated change principals where appropriate, without masking risky changes.
• Build an evidence pack template: screenshots/exports + test record format.

Days 61–90 (operate and prove)

• Run at least one controlled test per environment tier and store results.
• Review alarm history for false positives; adjust patterns and routing.
• Add periodic verification: confirm trails still write to the log group, filters exist, alarms have actions.
• If you use Daydream for third-party and cloud control assurance, map the requirement to owners, attach evidence artifacts, and schedule recurring checks so the control stays “operating” between audits. ¹

Frequently Asked Questions

Does CIS 3.14 require Security Hub to be enabled?

The requirement is CIS AWS Foundations v1.2 3.14, and AWS Security Hub provides the mapping and a control identifier (CloudWatch.14). You can implement the metric filter and alarm without Security Hub, but Security Hub helps you monitor conformance. ²

Can I alert from EventBridge instead of a CloudWatch Logs metric filter?

CIS 3.14 specifically calls for a log metric filter and alarm for VPC changes, so replacing it with a different mechanism can create an audit gap. If you also use EventBridge, keep the metric filter + alarm as the benchmark-aligned control. ¹

What if we centralize CloudTrail into a single logging account?

Centralization is compatible as long as CloudTrail events arrive in a CloudWatch Logs log group where the metric filter runs, and the alarm routes to responders who cover all accounts. Document the topology so auditors can trace it. ²

Should the alarm trigger on every single VPC change?

Many teams start by alarming on any match, then tune based on expected change volume and automation. Your goal is to detect unauthorized or suspicious changes without drowning responders, so document your tuning decisions and keep evidence the alarm still fires on meaningful events. ³

How do we prove the control is operating effectively?

Keep an end-to-end test record: the CloudTrail log entry, the metric increment, the alarm state change, and the delivered notification or created ticket. Pair that with alarm history exports during the audit period. ²

What’s the minimum evidence set an auditor will accept?

Expect to provide the CloudTrail-to-log-group configuration, the metric filter configuration, the alarm configuration including actions, and an example of alert delivery. Without proof of delivery to a monitored channel, the control is often treated as incomplete. ²

Footnotes

1. CIS AWS Foundations Benchmark; AWS Security Hub CIS AWS Foundations mapping table

2. AWS Security Hub CIS AWS Foundations mapping table

3. CIS AWS Foundations Benchmark