How to Collect Vendor Monitoring Evidence for SOC 2 CC9.2

Disclaimer: This post is for educational purposes only and does not constitute legal or compliance advice. Consult a qualified auditor or compliance professional for guidance specific to your organization.

SOC 2 Type II audits are won or lost on evidence. You can have the right controls in place and still fail if you can't prove they were running continuously throughout the audit period.

Automated monitoring can document vendor availability and your responses to reported incidents. This guide covers that evidence workflow; monitoring alone does not establish that your organization meets CC9.2.

CC9.2 in one line

CC9.2 addresses assessing and managing vendor and business-partner risks. Its points of focus include engagement requirements, risk and performance assessments, responsibility, communication, issue handling, and relationship termination. Availability monitoring can support part of that work. See the AICPA Trust Services Criteria and agree the relevant controls and evidence with your auditor.

If you want the full concept — the role of vendor monitoring evidence in a CC9.2 review — read the companion explainer: SOC 2 Vendor Monitoring: What Your Auditor Actually Needs for CC9.2. This post is the practical, step-by-step how-to.

4 Things That Make Strong CC9.2 Evidence

The following records can support a review of your vendor-monitoring controls. They are not a complete CC9.2 evidence package or a guarantee of acceptance. Confirm the scope, period, and format your auditor needs before collecting them.

1. Vendor Inventory

A documented list of all third-party service providers that your system depends on. This isn't just AWS and your database — it includes every SaaS tool in your critical path: payment processors, authentication providers, CDNs, email delivery services, monitoring platforms, and any API your product calls in production.

Auditors want to see that you know what you depend on. A vendor missing from the inventory is a gap worth closing before the audit.

2. Continuous Monitoring Evidence

Retain timestamped observations, incident records, and the monitoring configuration for the period your process covers. Record gaps and changes in coverage.

A single screenshot shows a point in time. Historical observations can give a fuller picture of how monitoring operated; agree the necessary evidence with your auditor.

3. Incident Response Documentation

During your audit period, some vendor will have had an outage. Auditors expect to see documented evidence of:

When the incident was detected
How your team was notified
What the impact was on your product or customers
When the incident was resolved

If you can't show this, it raises questions about whether your monitoring was actually running.

4. Alert Configuration Proof

Passive logging isn't enough. Auditors want proof that you had active monitoring configured — that alerts were set up to notify your team when a vendor's availability degraded. This means showing your alert rules, notification channels, and that the configuration was in place throughout the audit period.

Manual vs. Automated: A Realistic Comparison

Most teams start with a manual approach. Here's why it stops working when an audit shows up.

	Manual Approach	Automated Approach
Vendor inventory	Spreadsheet, manually updated	Monitored vendor list with tracking start date
Uptime tracking	Monthly status page screenshots	Continuous 5-10 min polling, full time-series data
Incident history	Slack messages, support tickets	Timestamped incident log with start/end/duration
Alerts	Manual checks or vendor-sent emails	Real-time alerts via email, Slack, webhooks
Evidence format	Assembled during audit scramble	Exportable PDF report, shareable links, always current
Audit prep time	Days (finding and organizing records)	Minutes (generate report)
Coverage gaps	Likely — manually assembled history has holes	Minimal — monitoring runs continuously in background

The manual approach works fine for day-to-day awareness. It breaks down when you need 12 months of continuous, consistent, auditor-legible evidence.

Step-by-Step: Setting Up Vendor Monitoring for CC9.2

The following steps set up a repeatable availability-monitoring evidence workflow.

Step 1: Inventory Your Critical Vendors

Start with your architecture diagram and work outward. For each vendor, ask: if this service went down at 2am, would my product break?

Typical categories to cover:

Cloud infrastructure: AWS, GCP, Azure, Cloudflare, Vercel, Render
Databases and storage: PlanetScale, Supabase, Neon, MongoDB Atlas
Payments: Stripe, Braintree, PayPal
Authentication: Auth0, Clerk, Okta
Communications: Twilio, SendGrid, Mailgun, Postmark
Observability: Datadog, Sentry, PagerDuty, Grafana Cloud
Other SaaS: Anything else in your critical path

Document this list. It becomes your vendor inventory for CC9.2.

Step 2: Set Up Continuous Monitoring

Choose a monitoring frequency appropriate to the vendor risk and the controls you intend to operate. Automated checks can help collect observations consistently, but this article does not prescribe an audit-required polling interval.

Status page monitoring works by reading the official status feeds that vendors publish (most major SaaS and cloud providers maintain one). A monitoring tool aggregates these, detects degradations, and builds a historical record automatically.

Document how the monitoring process actually ran, including the observation period, check frequency, failures, and any manual steps.

For tools that support this at scale, see Statusfield's compliance page — we monitor thousands of vendors out of the box.

Step 3: Configure Alerts

Active alerts are how you prove you weren't just passively logging data. Configure notifications so that when a vendor degrades:

Your on-call engineer gets an alert immediately
It routes to your incident response channel (Slack, PagerDuty, etc.)
Webhooks can trigger runbook automation if you have it

Save your alert configuration. A screenshot or exported config is your proof of active monitoring when the auditor asks.

Good alert channels to configure:

Email — baseline; good for non-critical services
Slack — best for team awareness and incident response
Webhooks — integrate with PagerDuty, OpsGenie, or custom runbooks

Step 4: Generate Compliance Evidence

This is where the value of automated monitoring pays off. Instead of assembling evidence manually, you generate a compliance report:

Per-vendor uptime percentages (30-day, 90-day, 12-month)
Complete incident log with timestamps, severity, and duration
Component-level breakdown (not just "is AWS up?" but which AWS services and regions)
Monitoring methodology (what's being monitored, how often, since when)

The report should be exportable as a PDF you can attach directly to your audit evidence package. Bonus: a shareable live link lets your auditor verify the data is real and current — not assembled for the occasion.

If you need a ready-made compliance report format, Statusfield's compliance reports are designed specifically for this purpose.

Two ways to deliver CC9.2 evidence:

PDF export: Generate a compliance report and attach it to your evidence package. Include it alongside your other CC9.2 documentation (vendor agreements, security questionnaires, etc.).

Shareable link: Some monitoring platforms let you share a live compliance view. This is useful if your auditor wants to explore the data interactively or verify it's pulling from a real monitoring system, not a manually assembled spreadsheet.

When sharing, make sure the report includes the monitoring start date for each vendor — auditors will check that monitoring predates the incidents you're showing them.

What Your Compliance Report Should Include

A vendor availability-monitoring evidence document can include these sections:

Service Inventory

A table of every monitored vendor with:

Service name
Category (infrastructure, payments, auth, etc.)
Monitoring start date
Current status

Per-Service Uptime Metrics

For each vendor in your inventory:

30-day uptime percentage
90-day uptime percentage
12-month uptime percentage (or since monitoring start if under 12 months)

Incident Log

Every detected incident during the audit period, with:

Vendor name and affected component
Incident start timestamp (UTC)
Incident end timestamp (UTC)
Duration
Severity (partial or major outage)
Brief description

Monitoring Methodology

A short section describing how you monitor: what data sources are used, how frequently, what constitutes a detected incident. This is important — auditors want to understand the method, not just read a table of numbers.

Disclaimer

Include a note that the report reflects third-party status feed data and is supplementary to, not a replacement for, your vendor's own SLAs and your internal incident documentation.

Common CC9.2 Mistakes to Avoid

These patterns can leave gaps in your vendor-monitoring evidence.

Monitoring only your own infrastructure

It's common to have excellent monitoring of your own servers and zero monitoring of the vendors those servers call. CC9.2 is specifically about third-party vendors. Internal monitoring doesn't satisfy it.

Relying on vendor SLA claims

A vendor telling you they have 99.9% uptime is not evidence that they met it during your audit period. What strengthens your evidence is an independent, timestamped record of vendor-reported status — captured as events happen and held on your side, not a summary the vendor assembles after the fact.

No incident response documentation for vendor outages

When Stripe had a 45-minute payment degradation at 11am on a Tuesday during your audit period, your auditor will ask what happened. "We didn't notice" is a bad answer. "We detected it at 11:03am, notified customers at 11:15am, and it resolved at 11:47am" is a good one.

Waiting until audit time to gather evidence

If you start monitoring the week before your audit, you have a week of data. Auditors reviewing a 12-month Type II audit will notice. Start monitoring early — ideally at the beginning of your audit period.

Treating this as a checkbox

Report the period and vendors you actually observed. A quiet period can legitimately contain no incidents; missing observations should be disclosed rather than presented as proven uptime.

Putting It Together

Automated monitoring can reduce the work of collecting availability records. Your organization still needs to assess vendor risks, operate the relevant controls, document its responses, and work with its auditor on the broader review.

Start collecting records early enough to cover the intended review period, and state any gaps explicitly.

Setting up automated vendor monitoring is a one-time investment that pays off every audit cycle.

Start your CC9.2 evidence trail in Statusfield →

Compliance reports are on the Pro and Team plans, with a free trial. Statusfield monitors thousands of services out of the box and generates audit-ready evidence reports in one click — no manual assembly required.

This post is educational and does not constitute legal or compliance advice. For guidance specific to your organization's SOC 2 audit, work with a qualified auditor or compliance consultant.