How to Audit SaaS Vendor Access Controls and Incident Response

Most compliance teams treat vendor risk management (VRM) as a file-gathering exercise: request the SOC 2 report, save it to a folder, and mark the vendor as "approved."

This approach fails actual audits. For frameworks like SOC 2, ISO 27001, and HITRUST, auditors require evidence that you didn't just collect the documentation, but that you actually reviewed it for specific risks. Specifically, you must verify that the vendor's access controls and incident response mechanisms align with your own security policy.

Automating this review process is difficult because standard GRC tools often stop at file collection. This article outlines exactly what evidence you need to extract from vendor reports to prove you’ve audited their access and incident response controls effectively.

What Access Control Evidence Should You Look For?

When you open a vendor’s SOC 2 Type II or ISO 27001 certification package, you need to validate specific controls. A generic "pass" isn't enough. You are looking for evidence that their internal access standards meet your requirements for data protection.

Focus your review on these specific areas within the vendor's "Section 4" (Description of Criteria and Controls):

1. The "Role-Based" Reality Check

Many SaaS startups claim to use Role-Based Access Control (RBAC), but their audit report shows exceptions where developers have direct database access.

• What to check: Look for testing results related to CC6.1 (Logical Access).
• Red flag: If the auditor noted "Exceptions Identified" regarding developer access to production environments, you must document a mitigating control (e.g., "Vendor uses read-only replicas for debugging").

2. Offboarding Timeliness

Your policy likely requires you to offboard employees within 24 hours. Does your vendor do the same?

• What to check: Look for CC6.2 (User Access Provisioning/Deprovisioning) testing samples.
• The evidence you need: If the vendor's SLA for offboarding is 5 days, but your contract states 24 hours, this is a compliance gap. You need to document this discrepancy and either accept the risk or request a contract amendment.

3. MFA Enforcement Evidence

Ideally, you want proof that the vendor enforces MFA on their own employees accessing your data, not just that they offer MFA to you as a customer.

• What to check: Search for "Multi-Factor Authentication" in the administrative security section.
• Verification: Ensure the report states that MFA is "enforced" for administrative consoles, not just "available."

How to Audit Vendor Incident Response (Without a Real Incident)

Verifying a vendor's Incident Response (IR) capability is harder because you can't simulate a breach on their systems. However, you can audit their preparedness evidence.

For ISO 27001 A.5.24 (Information security incident management planning) and SOC 2 CC7.3, you need to verify:

1. Notification SLAs: Does the contract or security addendum specify when they must tell you about a breach? "Without undue delay" is vague. "Within 72 hours" is specific.
2. Communication Channels: Do they have a dedicated status page or security alert email?
3. Past Performance: Check their status page history. A vendor with 99.99% uptime and zero reported incidents in 5 years is statistically unlikely and may indicate poor transparency rather than perfect security.

Where Traditional VRM Automation Stops

Many GRC platforms (like Vanta, Drata, or Hyperproof) automate the sending of security questionnaires and the storage of SOC 2 reports. They do not automate the analysis of the evidence inside those reports.

Feature	Standard VRM / GRC Tools	What Auditors Actually Require
Document Collection	Automatically requests and stores SOC 2 PDFs.	Acceptable.
Control Review	Checks if a file exists.	Insufficient. You must document what you reviewed inside the file (e.g., "Reviewed Section 4, noted exception in Control 6.1").
Bridge Letters	requests them automatically.	Insufficient. You must verify the dates cover your audit period.
CUECs	lists them generically.	Insufficient. You must document how your company implements the Complementary User Entity Controls (CUECs) required by the vendor.

If you rely solely on a GRC tool's green checkmark indicating "Report Uploaded," you may fail the qualitative portion of your own audit.

How to Document Your Review for Internal Audit

To satisfy your internal auditor or external assessor, you need to create an audit trail of your review process. You cannot simply say, "I read the report."

Step 1: Create a Review Artifact For every high-risk vendor, create a standardized review document (a Jira ticket, a confluence page, or a PDF form) that explicitly lists:

• Vendor Name
• Report Date & Type (e.g., SOC 2 Type II, Jan-Dec 2025)
• Reviewer Name
• Access Control Check: "Confirmed MFA enforced for admins."
• Incident Response Check: "Confirmed notification SLA is 72 hours."
• Exceptions Noted: "None" or list specific failures found in the report.

Step 2: Capture Evidence of Configuration Don't just trust the report; verify the settings you control.

• Screenshot: Capture the "Settings > Security" page of the SaaS tool showing that you have enabled SSO or MFA for your team.
• Screenshot: Capture the "Notification Settings" page showing you are subscribed to their security alerts.

Step 3: Map CUECs to Internal Controls Most SOC 2 reports list CUECs—responsibilities you must handle (e.g., "User must revoke access upon termination").

• Create a mapping table: "Vendor requires us to revoke access within 24 hours → Mapped to Internal Control HR-04 (Offboarding)."

Automating the Evidence Collection

While you must manually interpret the vendor's SOC 2 report (until AI agents become reliable enough to parse legal exceptions), you can automate the evidence of your own configuration.

Using automated evidence collection tools, you can script a workflow that:

1. Logs into the SaaS vendor (e.g., Salesforce, AWS, Slack).
2. Navigates to the security settings page.
3. Takes a screenshot proving you have configured the access controls correctly.
4. Appends this screenshot to your vendor review ticket.

This turns a subjective "I checked the settings" claim into objective, audit-ready proof.

Learn More About Internal Audit Evidence Automation

For a broader look at modernizing audit workflows, see our guide on automating internal audit evidence collection, which details how to move from manual sampling to continuous verification.