How Vantalect and Acumen Defensive Take the AWS Work Off Your SOC 2 Plate

Picture a 38-person startup with a signed term sheet and two conditions in it: every critical security finding closed, and a SOC 2 Type 2 report. Eighteen of its newsroom customers' vendor reviews ask for the same report. Production runs on AWS, in one account the founders created by hand.

The company has a CPA firm to hire, policies to write, and an observation window to schedule. It also has an AWS estate that nobody can describe in an hour, and that is the part with the most system-generated evidence.

The company is Tidepost, the fictional startup in Vantalect's published sample reports. Every figure about it below comes from those reports.

This guide is the companion to Preparing for a SOC 2 Type 2 Audit, which explains the audit itself. Here the question is narrower: of the work that lives in AWS, how much do Vantalect's engagements and Acumen Defensive's tools take on, and what is left for you? The honest answer is a useful slice, and it is not the audit.

Who Does What

Four parties touch a SOC 2 Type 2 audit. Only one of them issues the report.

Acumen Defensive, LLC builds and licenses the cloud assurance tools, and Vantalect runs every engagement with them. Some of the tools are only partly built, and the section below says which. The tools find and measure; the engagements fix and hand over.

Two cautions apply to the rest of this guide.

First, nothing Vantalect produces is an audit opinion. Its SOC 2 map in the Tidepost sample says so: "Vantalect is not the auditor and does not issue, predict, or influence a SOC 2 report."

Second, auditors validate the data they are given. A scan report or compliance map points to evidence; it is not evidence. The evidence is the record behind it: the CloudTrail event, the Config history, the credential report, the pull request. Audit firms also guard their independence, so tell yours early which consultants designed which controls.

The Tools, Said Precisely

Pathfinder (formerly Sonde) is a read-only survey of AWS. Point it at an account or an organization and it collects an inventory, downloads logs, evaluates the inventory against control catalogs, and produces a findings report. It can only call Describe, List, Get, and similar reads, refuses reads that expose secrets, and logs every call it makes. It writes nothing to the account. It is partly built: it runs locally and in replay today, and its hosted pipeline is planned.

Its catalogs today are the CIS AWS Foundations Benchmark, AWS Foundational Security Best Practices, an implementation of the Trusted Advisor checks, and two Pathfinder catalogs of security and operations checks: 113 rules in five packs, per the September 16, 2026 build plan. Some packs are only partly implemented, and each reports its own coverage. Pathfinder does not print a SOC 2 report today.

The SOC 2 crosswalk is data in Acumen's compiled engine, which is still being built. It links catalog rules to SOC 2 criteria. We counted it from soc2.yaml on October 30, 2026:

• The file lists 33 criteria. It says its inventory is partial, so 33 is not the number of criteria in SOC 2.
• 13 of the 33 have at least one rule mapped from an AWS-published source, the SOC 2 framework in AWS Audit Manager, which AWS says cannot verify compliance: 59 distinct rules and 68 mappings.
• The other 20 have no AWS-published mapping. For them the file holds only asserted mappings, which its coverage report excludes from the count (193 across the whole file: 147 from the open-source Prowler project's SOC 2 mapping and 46 from a simulated SOC 2 map).

That is "13 of the 33 criteria the file lists have an AWS-published rule behind them," not "Pathfinder covers 39 percent of SOC 2." A rule that checks a setting is not a control that passes an audit.

The pattern is the useful part. Rules exist where a setting can be read from the account: encryption, network exposure, root multi-factor authentication, whether GuardDuty is on. They do not exist for who approved a change, who reviewed access last quarter, or whether anyone tested a restore. Those need a person's evidence, and the rest of this guide follows that line.

Aegis scans source code (static analysis, dependencies, secrets, infrastructure as code, containers) under one findings model, with suppressions that carry a justification, an expiry, and an approver. It is partly built: it exists today as a tool for Renkara's own repositories, and packaging it for clients is planned. Its findings could feed the vulnerability and code-review evidence an auditor looks at, though no Acumen file maps it to SOC 2 criteria. It is not part of the engagements below.

Interceptor follows a principal (an access key, a role, an IP address) across an AWS organization and rebuilds its sessions afterward. It is built, and so far proven only on a sample organization, with no live client case yet. It is an incident instrument for the day you respond to a real incident (the CC7.3 to CC7.5 area, though no Acumen file maps it to SOC 2 criteria), and it is propose-only: it writes containment runbooks with an approval step and never runs one.

Red Cell, Acumen's external-testing tool, is planned and not part of these engagements. Many auditors and buyers expect an annual penetration test, and the security audit below is explicitly not one, so budget for one separately.

The Engagements, in SOC 2 Terms

Three engagements produce AWS-side SOC 2 evidence. All are fixed price and start from a read-only role you deploy. Member accounts change only as code, through your pipeline; the Foundation's Build also uses a narrow management-account role that exists only in change windows you approve in writing. Prices are as of October 30, 2026; the terms govern.

The AWS Security, Compliance & Governance Audit (page), a technical review of your AWS estate and not a SOC 2 audit, is two weeks for $25,000. It scans every account and enabled region against the CIS and AWS benchmarks, verifies the critical and high findings by hand, reviews identity and governance, and maps the result to one framework. The Hardening is the Audit plus four more weeks, six weeks and $35,000 in all: criticals closed as code, guardrails at the top of the organization, single sign-on, detection in every account, an organization trail into an archive no application account can alter, and runbooks. Half the fee is invoiced only when every critical finding is closed, as the week-six re-scan verifies; a critical you accept in writing counts as closed. That gate measures criticals. It does not measure the report.

The AWS Multi-Account Foundation (page) puts the accounts in the structure AWS recommends: a landing zone, a Security organizational unit with Log Archive and Audit accounts, one organization trail, inherited guardrails, one way to make the next account, and central backup. The structure is public on the best-practices page. It is $25,000 for the two-week Blueprint or $35,000 for the six-week Build, and after a security engagement the Build takes four weeks for $25,000. Its gate is 13 read-only checks, run by a script you can read.

The AWS Well-Architected Framework Review (page) reviews one workload against six pillars. For SOC 2 it matters twice: the reliability work (backups, restore checks, quotas, recovery targets) is Availability evidence, and the operations work (on-call, runbooks, a tested incident process) supports CC7.

Criterion by Criterion

For each area: what a Pathfinder survey checks, what the security engagement produces, what the Foundation sets up, and what the auditor receives.

CC6: Logical Access

CC6 asks who can reach your systems and data, how access is granted, reviewed, and removed, and what stands at the boundary.

Pathfinder checks. The crosswalk's AWS-published mappings are densest here: 19 rules for CC6.1 (root and console-user multi-factor authentication, admin and wildcard policies, KMS key rotation, encryption at rest), 11 for CC6.6 (open SSH, web application firewall and network firewall settings), 16 for CC6.7 (TLS on load balancers, CloudFront, and data stores), and one for CC6.8 (GuardDuty on). For CC6.2 and CC6.3, provisioning and removal, the file holds only community mappings. The survey reads the raw material, but a person has to read it against your roster.

The security engagement produces. An identity and access review: human access, workload roles, cross-account trust, long-lived keys, privilege-escalation paths, and the root and break-glass accounts. In the Hardening, people move to single sign-on with multi-factor authentication, long-lived keys are retired, over-broad roles are cut to what each workload uses, and the root user is locked down. The findings register dates each fix.

The Foundation sets up. IAM Identity Center connected to your identity provider, no IAM users in workload accounts, service control policies that deny leaving the organization or disabling the trail, Config, and detection, and centralized root access. These stop a setting from drifting back after the engagement ends.

The auditor receives. IAM credential reports, root-task records from the organization trail, Identity Center assignments and sign-in events, policy attachments, Access Analyzer findings, and Config history for security groups and databases. Vantalect lists where each lives and when it began operating. The auditor decides the sample.

Stays with you. The access review. Auditors test that a named reviewer compared the assignments against the HR roster each quarter and signed. Vantalect can write the procedure into the handover; it cannot be the reviewer. In a 2024 CBIZ study of 193 SOC 1 and SOC 2 reports, user access reviews caused 15.6 percent of exceptions.

CC7: System Operations and Monitoring

CC7.1 and CC7.2 ask whether you detect configuration changes, vulnerabilities, and anomalies. CC7.3 through CC7.5 ask whether you evaluate, respond to, and recover from incidents.

Pathfinder checks. For CC7.1 and CC7.2 the crosswalk has two and four AWS-published rules: alarms with actions, GuardDuty, Security Hub, image scanning, and WAF rule-group metrics. CC7.3 to CC7.5 have community mappings only, because triaging an alert is not a setting.

The security engagement produces. In week five of the Hardening, GuardDuty, Security Hub, IAM Access Analyzer, and Config go on in every account and region, routed to your on-call. One organization trail goes into a log archive, and runbooks cover the findings most likely to page you. The alert route is tested, and the time is recorded.

The Foundation sets up. The Audit account as delegated administrator for detection, new accounts enrolled automatically, Config aggregated, and the Log Archive account. That is the difference between detection on in the accounts someone remembered and detection on in the account made next month.

The Well-Architected engagement adds. Alarms on service-level objectives, an on-call rotation, and an incident process exercised in a tabletop with a post-incident review step: the operating evidence for CC7.4 and CC7.5.

The auditor receives. Trail and Config history, findings, alarm history, the on-call schedule, and the tabletop record. Stays with you: triage and the incident log; a real incident in the window becomes a sample. Vantalect's incident response and breach forensics engagements exist for that day; they are separate from SOC 2 preparation.

CC8: Change Management

CC8.1 asks that changes are authorized, tested, approved, and implemented. The proof is mostly outside AWS: tickets, pull requests, approvals, and pipeline logs live in your Git host and tracker.

Pathfinder checks. The crosswalk holds no AWS-published rule for CC8.1; its four mappings are community assertions. Pathfinder can read some of what AWS holds, such as CloudFormation drift. It cannot show that someone other than the author approved a change.

The security engagement produces. Every Hardening fix is code in your repositories, reviewed by the engineer who owns the account and applied by your pipeline, with a twice-weekly change review in weeks three through five. Those pull requests are real CC8.1 evidence for the changes made in the engagement. They do not cover next year's.

The Foundation sets up. One reviewed way to make an account, and policy changes proven in a staging unit first.

The Well-Architected engagement adds. In the Tidepost sample, the control was production changes only through a pull request and the pipeline, developers read-only in production, console-built resources imported into code, and scheduled drift reports, operating from March 27, 2026.

The auditor receives. Pull requests with approvals, pipeline runs, and drift reports, with CloudTrail showing that console changes did not bypass them. Stays with you: the approval culture. If engineers can merge their own changes to production, an engagement can make that visible and cannot make it stop.

CC3 and CC9: Risk

CC3 is your risk assessment. CC9 is risk mitigation for business disruption and for vendors. Both need a program with an owner, a calendar, and documentation, which is management's work. The Tidepost map lists CC1 through CC5 and CC9 as Tidepost's own, not touched by the engagements.

What the engagements feed. The findings register ranks every finding by exploitability and blast radius, and each risk accepted instead of fixed is recorded in writing with a named signer, a reason, and a closing date. In the Tidepost sample, one public database was accepted until a cutover on March 22, 2026, and three recommended steps were declined, each with a written reason. These are inputs to your assessment and treatment plan.

AWS as a vendor. Under the usual carve-out method, AWS is a subservice organization: your system description names it, describes what it provides, and lists the controls you expect it to run, while its controls over data centers, hardware, and virtualization are excluded from testing. Your CPA firm tests your monitoring of AWS, usually your documented review of its SOC report from AWS Artifact. Many of the AWS-side controls on the map are the kind of complementary user entity controls AWS's report expects you to run; check them against the actual list. AWS's own pages describe that report's categories differently from one another, so check the current names in Artifact. Every other vendor with access to your data is yours to inventory, review, and contract with.

A1: Availability, If You Choose It

Security is the only required category. Availability adds capacity (A1.1), backup and recovery infrastructure (A1.2), and tested recovery (A1.3).

Pathfinder checks. One AWS-published rule each for A1.1 (alarm settings) and A1.2 (backup plan frequency and retention). A1.3 has only a community mapping, and it is the one that matters: auditors usually want proof that you restored something.

The Foundation sets up. Backup policies on organizational units and a separate Central Backup account, so a compromised workload account cannot delete its own recovery points.

The Well-Architected engagement produces. Failure-mode analysis against your recovery targets, quota monitors, restore checks, and recovery runbooks; in the Tidepost sample, the drill record behind A1.3.

Stays with you. The restore test, on a schedule, with a record. "When did you last restore from backup?" should have a date and a document for an answer.

The Map in One Table

What Vantalect Does Not Do

Read this before signing anything.

• Issue the report. Only a licensed CPA firm can. Vantalect does not audit, attest, or certify, and does not predict or influence the opinion.
• Guarantee a clean report. No scan, map, or hardened account does. Auditors choose their tests and samples, and a report can carry exceptions and still be unmodified.
• Run your people and policy controls. Background checks, onboarding and offboarding, security awareness training, the control environment (CC1 and CC2), and the written policies and plans (CC5) are management's. We supply the AWS facts to put in them and the runbooks for the AWS part.
• Write the system description or sign the assertion. Management owns both.
• Run your vendor reviews. Inventory, due diligence, and review of vendors' SOC reports (CC9.2) are yours.
• Do your recurring work. Quarterly access reviews, restore tests, and monthly control reviews stay with you. We write the procedure and hand it over; after the closing readout, support is outside scope unless a change order says otherwise.
• Perform a penetration test. The security audit is not one, and Red Cell, which is planned, is not part of these engagements.
• Cover anything outside AWS. Your identity provider, Git host, laptops, and any other cloud are in scope for SOC 2 if they are in your system. The engagements touch them only where AWS connects (Identity Center to your identity provider, the pipeline to your Git host) and do not review or evidence them.
• Act as your compliance platform. We hand over documents, not a feed.

A Realistic Sequence

Audit-side durations are conventions reported by audit firms and vendors, and they vary. The engagement lengths are Vantalect's, fixed.

Before anything. Pick your CPA firm, your categories (Security, plus any of Availability, Processing Integrity, Confidentiality, and Privacy that customers expect), and the date you want the observation window to open. Everything else is sequenced against that date, and the firm may have views on evidence that you should hear first.

Weeks 1 and 2: the Audit. The read-only role goes in, the scan runs, the criticals are verified by hand, and you receive the findings register, the identity review, the SOC 2 map, and a roadmap. Your sponsor agrees at the readout which findings are critical. This is your readiness picture from the AWS side.

Weeks 3 to 6: the Hardening, with the Foundation alongside. Criticals close, identity moves to single sign-on, detection goes on everywhere, and the account structure goes in. The week-six re-scan repeats week one's checks and hands over the before and after.

Weeks 6 to 12: the gap. Your own work comes next: policies approved, the CPA firm's readiness assessment, access reviews run once for practice, restore tests, and the Well-Architected work if Availability is in scope. A control that starts after the window opens leaves the auditor to decide what that means for the report. The gap exists so that every control has a start date before the window does.

The window. Per audit-firm and vendor sources, three months is the usual minimum, six is common for a first report, and twelve for renewals. The work is repetitive on purpose: a monthly review of Security Hub failures and Access Analyzer findings, the quarterly access review, a periodic re-scan to catch drift, and a record of each.

Fieldwork and the report. Fieldwork commonly runs one to six weeks and the report follows two to six weeks later. A bridge letter, which your management writes and the auditor does not, covers the time after an issued report's period, so it starts helping once your first report exists. Between the window's end and that first report, give the buyer the expected report date and, if your CPA firm agrees to write one, a letter confirming the examination and its period. Vendors quote 6 to 18 months for the whole path to a first Type 2 report. In the Tidepost sample, the AWS portion took about the first 12 weeks.

The Tidepost Example

Tidepost is fictional: its people, accounts, investors, and figures are invented for the sample, and any resemblance to a real company is coincidental.

The company has 38 employees, 15 engineers, 600,000 monthly users, and one AWS account the founders created. Its Series A term sheet (December 2025) required every critical finding closed and a SOC 2 Type 2 report. Its lead investor required Security, Availability, and Confidentiality, and its CPA firm set the observation window from April 1 to September 30, 2026.

January 5, 2026: the Audit. The week-one scan covered one account. Of 50 checks, 12 passed (24 percent). The register held 47 verified findings: 10 critical, 14 high, 15 medium, and 8 low. The criticals included a root user with two active access keys and no multi-factor authentication, a public bucket of 104,318 user records, and a public media bucket whose images carried location metadata. The first fixes landed on January 6.

January 16: the readout. The sponsor agreed the 10 criticals and accepted one in writing until a database cutover on March 22.

January 21 to February 13: the Hardening and the Foundation, together. The landing zone went in January 21, the founders' account joined as tp-prod on January 28, and nine accounts were in place by February 13. On February 12 the same scan ran across nine accounts: 45 of 50 checks passed (90 percent). Each of the five that did not had a recorded disposition: two accepted in writing, one deferred with written acceptance, and two declined with reasons. The gate passed, with nine criticals closed and one accepted in writing. The Foundation's re-scan passed 11 of the 12 checks agreed at its readout (the scan has 13) and waived the twelfth in writing.

The SOC 2 technical map at handover. It listed 35 AWS-side controls across CC6, CC7, CC8, A1, and C1. Twenty-two were operating on February 12, each with an "operating from" date and a pointer to its evidence. Eleven more were planned for March, from the Well-Architected work. Two, a retention schedule and a deletion pipeline under Confidentiality, were planned for May 20, after the window opened, because they waited on counsel and the app team. The map says so plainly: "The auditor decides what that means for the report."

What the map did not touch. The control environment, the risk assessment program, the written policies, vendor management, and the system description belonged to Tidepost's compliance owner. Its CPA firm's readiness assessment ran February 17 to March 6, in the gap.

What Tidepost took over. A monthly review from March 10, a quarterly access review (the Identity Center export compared with the HR roster) from March 31, and a re-scan from May 12, each with a named owner. Vantalect's operator role was deleted February 13, and the re-scan proved it. About twelve weeks after the first scan, the window opened. Whether the report is clean depends on the next six months of Tidepost's own work, and the sample does not pretend otherwise.

The reports are at the Tidepost sample, with the security engagement and the Foundation on their own pages.

Where to Start

If you are weeks from picking a CPA firm, read the preparation guide first.

If your auditor has named a window date and the AWS side worries you, start with the Security, Compliance & Governance Audit. If your accounts are a handful made by hand, ask about the Multi-Account Foundation in the same conversation. If Availability is in scope, the Well-Architected review produces the recovery evidence.

Write to the address on those pages with your account count, your framework, and your window date. The reply says which you need.