Vendors who support your production AWS account are in your access story whether you like it or not. A questionnaire that says they “use MFA” does not tell an auditor who assumed which role last quarter. Rutagon builds SOC 2 vendor access evidence as an AWS-side packet: the role the vendor is allowed to assume, the external ID or federation constraint, the CloudTrail assume events, and the offboarding time when the engagement ends. This is not a vendor-risk questionnaire template dump.
Mid-market SaaS companies often grant a vendor an IAM user key “so they can help for a week” and then keep the user. Or they attach a managed policy that is wider than the ticket. The GRC platform stores the SOC questionnaire. It does not store the assume-role trail.
We show what you can show. If you cannot show it, we build the role and the logging so you can.
SOC 2 Vendor Access Evidence for an AWS Account
SOC 2 vendor access evidence starts from a named engagement: vendor, purpose, accounts, and end date. We create or tighten an IAM role the vendor assumes, with an external ID you generate and they must present. We deny standing IAM users for that vendor. We turn on the trail that already should exist and we prove AssumeRole events for that role land in a bucket the vendor cannot delete.
The packet for a period is the role policy, the trust policy, the external ID rotation (if it rotated), CloudTrail assumes (who, when, source, session), and the ticket that authorized the window. If there are zero assumes, that is a valid sample: access existed, unused. Unused still needs an expiry.
Questionnaires can sit in GRC as a parallel artifact. They do not substitute for the AWS packet. Evidence freshness applies: a role screenshot from month one of a Type 2 window is stale if the trust changed.
What Auditors Actually Ask
They ask who can reach production and how you remove that reach. For a vendor, “they have an account in their IdP” is not an answer unless you federate and can show the subject. Most mid-market vendor access is still a role in your account. The answer is the role ARN, the trust, and the revoke.
They may pick a day and ask whether the vendor was in the account. CloudTrail answers that. A Slack thread does not. We keep the query and the result set with the packet.
If the vendor used a shared user named vendor-support, we replace it. Shared users cannot be attributed. Attribution is the evidence.
Config conformance can flag IAM users with keys. Vendor roles should not need those users. The finding is the user, not the vendor brand.
engagement: vendor-observability
account: prod
role: VendorReadProd
trust: external-id-required
window: dated
assumes_in_period: listed
ended: role-trust-removed
AWS documents external IDs for third-party access. We use that control. We do not invent a second secret in a spreadsheet as the only gate.
What We Do Not Deliver Here
We do not deliver a hundred-question SIG or a scoring rubric. We do not claim that a clean AWS packet makes the vendor’s own SOC report unnecessary for your procurement team. Those are parallel tracks. This track is your account.
We do not name the vendor’s product as a control. The control is your role, your trail, your expiry. If the vendor insists on a long-lived key, that insistence is the finding we bring to the diagnostic.
Security automation is how the packet is assembled on a schedule, not once when the auditor emails.
Session names, source IPs, and the week the vendor finished
AssumeRole events can look identical if every session is named vendor. We require a session name convention you control: engagement ID plus a human or automation ID the vendor can actually send. If they cannot set session name, we still have source IP, user agent, and time. Attribution gets weaker and we say so in the packet. Pretending a shared session name is a person is how samples collapse.
Source IP ranges from the vendor should be known or explicitly unknown. Unknown is allowed if you record it. A role assumable from the entire internet with only an external ID is weaker than a role that also has a source condition you can operate. We do not invent a CIDR you cannot maintain. We do record whether a source condition exists.
When the engagement ends, trust removal is the control. We remove the vendor principal from the trust, or we delete the role if nothing else uses it. We keep the CloudTrail history. We add an end packet: who requested removal, when trust changed, and a post-window query that shows no new assumes. A role left “in case they come back” is standing vendor access.
Break-glass for a production incident is a new, short engagement, not a revival of the old role by Slack. New external ID, new window, new packet. Reusing last year’s role because the ARN is already in their runbook is how leftover access returns.
Read-only vendors still get the same shape. Read-only is a policy, not an excuse to skip the trail. Data-plane reads on production data are still access. The packet should say which APIs the role allows. ReadOnlyAccess managed policy is a coarse story; a tighter policy is a better sample if you can name the APIs they need.
If the vendor also holds a role in a sandbox account, that is a second packet or a clearly listed second account on the same engagement. Mixing prod and sandbox assumes in one unexplained list is how an auditor thinks sandbox activity is production. Account ID on every row.
We do not turn this into a vendor security questionnaire. Your procurement team can still send those. This packet is what happened in your AWS account. Security automation is how it is rebuilt each period without a hero export the week fieldwork starts.
Frequently Asked Questions
Is a vendor’s SOC 2 report enough evidence of their access to our account?
No. Their report describes their environment, and your packet describes their principal in yours. You need both if they touch production. One does not replace the other.
Can we give the vendor an IAM user if we rotate the key?
Rotation is still a standing user. AssumeRole with an external ID (or federation) is the target. A user key is a bridge with a deletion date. If the vendor cannot assume a role, that is a capability gap to record, not a reason to skip the trail.
What if the vendor only needs console access?
Console can still be federated or assumed. A long-lived console password for a shared user is the worst shape. We prefer a role the vendor assumes into, with MFA on their side if they federate, and a short window if they cannot.
Do we keep CloudTrail events after the vendor is gone?
We keep the period that covers the engagement and the observation window your auditors care about, per your retention policy. Deleting the trail because the vendor left is how the sample goes empty. The role trust can be removed. The history should remain.
Ask us what your GRC platform isn't covering. Call 907-841-8407, email contact@rutagon.com, or use rutagon.com/contact.