Closing SOC 2 infrastructure findings on AWS without taking the system down

Published 25 October 2026 · SOC 2 · AWS · Drata / Vanta

When a company connects AWS to Drata or Vanta for the first time, the dashboard lights up red. For the US healthcare platform we operate, the first connection produced a long list of failing infrastructure tests on a system that serves clinical staff every day and cannot take a maintenance window on a whim.

This post is the order we work through that list, what each common finding actually requires, and which ones are a five-minute console change versus a planned cutover. It is written for the engineer who has been handed the dashboard and a deadline.

First: sort the list by what it costs to fix, not by what the tool says

Compliance tools rank findings by their own severity model. That order is fine for an auditor and wrong for an engineer, because it mixes "tick a checkbox" with "rebuild the database". Before touching anything, we put every finding into one of three buckets:

1. Config-only. A setting on an existing resource. No downtime, no data movement. Most of the list.
2. New resource. Something has to exist that does not yet: a trail, a log group, an alarm, a budget. Still no downtime, but it needs a design decision (where do logs go, who gets paged).
3. Cutover. The fix cannot be applied to the running resource. Encryption at rest on an existing RDS instance or EBS volume is the classic case. These need a runbook, a rehearsal and a window.

Bucket 1 and 2 go first because they move the dashboard fastest and they are the evidence that the programme is real. Bucket 3 is planned like any other migration, and there are usually only two or three of them.

The findings that come up every time, and what they really require

Logging and monitoring

• CloudTrail not enabled in all Regions / log file validation off. Create one organisation-wide or account-wide trail, multi-Region, with log file validation on, delivering to a dedicated S3 bucket with a lifecycle rule. Config-only, ten minutes, and it is the foundation for half the other evidence.
• No CloudWatch alarms for root use, IAM changes, security group changes. These come from a metric filter on the CloudTrail log group plus an alarm plus an SNS topic that reaches a human. The part teams miss is the last step: an alarm that goes to an unread topic is a failing control with extra steps.
• VPC Flow Logs disabled. Enable per VPC to CloudWatch Logs or S3. Decide the retention first; flow logs are cheap to write and surprisingly expensive to keep forever.
• GuardDuty / Security Hub / AWS Config not enabled. One click each, but Config in particular has a recurring cost that scales with resource churn. Enable it, then watch the bill for a month.

Identity and access

• Root account has access keys / no MFA. Delete the keys, add a hardware MFA, store the recovery in the company password manager, and stop using root. Record the date; the auditor will ask.
• IAM users without MFA, access keys older than 90 days, unused credentials. Rotate or delete. The lasting fix is to stop creating IAM users for humans at all: use IAM Identity Center or federated roles so there is nothing to rotate. For the healthcare platform this is also how we replaced shared logins with named, auditable access for our own engineers.
• Policies with * actions on * resources. The honest answer is that scoping every policy is a project. We do it in order of blast radius — anything a public-facing workload assumes first — and document the rest with a dated plan, which auditors accept when it is real.
• Password policy. Config-only. Set it to the tool's expectation and move on.

Network exposure

• Security groups open to 0.0.0.0/0 on 22 or 3389. Close them. If engineers need shell access, replace SSH with Systems Manager Session Manager: no inbound rule, no keys, every session logged. This single change clears a finding and removes a whole class of risk; it is the first thing we did on the healthcare platform and the one we recommend to everyone.
• RDS publicly accessible. Flip the flag — but first confirm nothing legitimate connects from outside the VPC. Anything that does (a BI tool, a developer's laptop) moves to a tunnel through SSM.
• Default security group allows traffic. Remove all rules from the default group in every VPC and never attach it to anything.

Encryption at rest

This is the bucket-3 section.

• EBS volumes unencrypted. Turn on default EBS encryption for the account and Region so new volumes are covered. Existing volumes cannot be encrypted in place: snapshot, copy the snapshot with encryption, create a new volume, swap it in. That is a stop-start of the instance, so it joins the cutover plan.
• RDS storage unencrypted. The same constraint: encryption at rest is set at creation. The route is snapshot → copy with a KMS key → restore to a new instance → cut the application over. On the healthcare platform we folded this into the same window as a planned engine upgrade so the team paid for one cutover, not two. Write the runbook, rehearse it on a non-production copy, and keep the old instance until the recovery window has passed — the same discipline as our RDS Blue/Green upgrade runbook.
• S3 buckets without default encryption / without Block Public Access. Config-only for both. Turn on Block Public Access at the account level, then fix the one bucket that actually needed to be public by serving it through CloudFront instead.

Backups and recovery

• RDS automated backups retention below the required days. Config-only; set the retention to what your policy says (we use 30 for healthcare) and note that it raises storage cost slightly.
• No tested restore. Tools cannot check this; auditors can and do. Restore the latest snapshot to a throwaway instance, run a query that proves the data is there, delete it, and keep the timestamps. We do this quarterly and attach the log to the evidence pack.

Evidence: what to keep as you go

The finding turns green on its own when the tool re-scans. The evidence does not. For every fix we keep, in a folder the client owns:

• the finding ID and the date it was closed;
• what changed, in one sentence, and the ticket or PR;
• a screenshot or CLI output showing the new state, with the account ID visible;
• for cutovers, the runbook and the go/no-go checklist as run.

When the auditor asks "show me", that folder is the answer, and the client's compliance lead does not have to chase an engineer for a screenshot from months ago.

The order, summarised

1. Sort by cost to fix: config-only, new resource, cutover.
2. Logging first — it is the evidence base for everything else.
3. Identity: root, MFA, keys, then policy scoping by blast radius.
4. Network: close inbound, move to Session Manager, un-public the database.
5. Encryption: account defaults now, existing volumes and databases in a planned window.
6. Backups: retention now, a rehearsed restore every quarter.
7. Keep evidence as you go, not at the end.

On the healthcare platform this ran alongside normal feature work, with the cutovers folded into planned windows and no unplanned downtime. The checklist is the one behind our fixed-price SOC 2 Remediation Sprint.