SOC 2 CC8.1 Evidence Guide: How to Prove Application-Level Change Management

SOC 2 audits require strict evidence for Change Management (CC8.1), specifically screenshots, approval tickets, and testing documentation. While most engineering teams have automated evidence collection for code changes via GitHub integrations, application-level changes—like toggling feature flags, updating admin panel configurations, or modifying permission groups—often remain a manual documentation gap. If you cannot prove these changes were authorized and tested, you risk a qualified opinion.

What Is "Application-Level" Change Management in SOC 2?

When auditors review CC8.1 (Change Management), they aren't just looking at your codebase. They are looking at any modification to the system that affects your service commitments.

Most teams nail the Infrastructure and Code side of this:

• Code: Pull Request $\rightarrow$ Code Review $\rightarrow$ CI/CD $\rightarrow$ Deploy. (Evidence: GitHub API).
• Infrastructure: Terraform plan $\rightarrow$ Apply. (Evidence: AWS CloudTrail).

However, Application-Level changes often happen outside these structured pipelines. These include:

• Feature Flags: Turning on a beta feature for a specific customer segment in LaunchDarkly.
• Admin Panel Configs: A support agent changing a customer's pricing tier or data retention policy in a custom internal tool.
• Low-Code/No-Code: Updating a workflow in Salesforce or a Zapier integration.
• CMS Updates: Changing legal terms or privacy policies on the marketing site.

Because these changes happen in a User Interface (UI) rather than a Command Line Interface (CLI), they rarely generate the clean, structured JSON logs that GRC platforms like Drata or Vanta rely on.

What Evidence Do Auditors Actually Request for CC8.1?

For every sample change the auditor selects (usually a random sample of 25-40 changes from the audit period), you must provide a "packet" of evidence. For application-level changes, this packet must include three distinct artifacts.

1. The Request (Authorization)

You need proof that the change was planned, not ad-hoc.

• The Artifact: A screenshot of a Jira ticket, Asana task, or Linear issue.
• Critical Detail: The ticket creation date must precede the change implementation date.
• Auditor Check: Does the description match the actual change observed in the system?

2. The Approval (Segregation of Duties)

You must prove that the person who implemented the change is not the same person who authorized it (unless you have a documented exception for small teams).

• The Artifact: A screenshot of the approval comment, the "Approved" status transition in Jira, or a Slack approval thread.
• Critical Detail: The name of the approver must be visible and distinct from the implementer.
• Auditor Check: Did the approval happen before the change went live?

3. The Validation (Testing)

You need to prove the change worked as intended and didn't break anything.

• The Artifact: A screenshot of the "Before" and "After" states in the UI, or a screenshot of a staging environment test result.
• Critical Detail: Timestamps are vital here. A screenshot without a visible system clock or metadata is often rejected.
• Auditor Check: Is there evidence that someone verified the change before closing the ticket?

Where Traditional SOC 2 Automation Stops

This is the friction point for most compliance managers. GRC platforms like Drata and Vanta are excellent at reading APIs. They can instantly pull a list of every Pull Request from GitHub and check if it had an approving review.

But they cannot see what happens inside your custom admin panel or third-party SaaS tools that lack robust audit APIs.

If an engineer logs into your internal "SuperAdmin" dashboard to manually increase a customer's API rate limit:

1. No Pull Request exists.
2. No CI/CD log exists.
3. The application log might just say "UPDATE user_config SET limit=5000".

To an auditor, that database log is insufficient because it doesn't show authorization or testing. It just shows the event.

This forces teams to manually take screenshots of the Jira ticket, the Slack conversation where the manager said "Go ahead," and the admin panel showing the new setting. Doing this for 25+ samples is tedious and error-prone.

How to Structure a CC8.1 Evidence Pack

To satisfy an auditor quickly, structure your manual evidence packs consistently. Do not send raw screenshots named Screen Shot 2026-02-19 at 10.42.12.png.

Create a PDF or a folder for each sample change containing the following:

Evidence Component	Required Visuals	Common Auditor Feedback
Change Ticket	Screenshot of Jira/Linear ticket including ID, Summary, Reporter, and Date.	"I can't see the creation date."
Approval Proof	Screenshot of the specific comment or status change approving the work.	"Who is 'dave_99'? I need a full name."
Test Evidence	Screenshot of the application UI showing the change working in Staging or Prod.	"This looks like a mock-up. Show me the URL bar."
Deployment Verification	Screenshot of the system log or UI showing the change is live.	"How do I know this actually went to production?"

Common Pitfalls That Fail CC8.1 Testing

1. The "Implied" Approval

Scenario: A developer opens a ticket, does the work, and closes it. They argue, "My manager prioritized this in the sprint meeting, so it was approved." The Fix: Verbal approvals don't count. If it's not written down (Slack, Jira comment, email), it didn't happen. You need a screenshot of that text.

2. Cropped Context

Scenario: Submitting a screenshot of just the "Save Successful" toast notification. The Fix: Auditors need context. Capture the full browser window, including the URL bar (to prove environment) and the system clock (to prove timing).

3. The "After-the-Fact" Ticket

Scenario: Creating a Jira ticket after the change was made just to satisfy the audit requirement. The Fix: Auditors compare timestamps. If the change log shows Feb 19th but the ticket was created Feb 20th, you will likely receive a deviation or exception in your report.

4. Self-Approval on Emergency Fixes

Scenario: A critical bug hits production. A senior engineer fixes it immediately without waiting for approval. The Fix: SOC 2 allows for emergency changes, but they require retroactive review. You must provide evidence that the change was reviewed and approved explicitly (usually within 24 hours) after the incident was resolved.

Automating the Visual Evidence Layer

Since APIs fail to capture the nuance of application-level changes, automation strategies must focus on the visual layer.

Tools like Screenata can act as a "wrapper" for these manual workflows. Instead of asking engineers to remember to take screenshots, you can trigger an automated capture sequence when a ticket moves to "Testing" or "Done."

For example:

1. Trigger: Jira ticket tagged app-config-change moves to Done.
2. Action: Screenata captures the Jira ticket details (authorization).
3. Action: Screenata logs into the Admin Panel, navigates to the relevant user config, and captures the current state (validation).
4. Result: A PDF evidence pack is generated and attached to the control in your GRC platform.

This approach satisfies the "Observation and Inspection" criteria auditors use when "Examination" (looking at logs) isn't enough. It ensures that even manual, UI-based changes have a rigorous, audit-ready paper trail without burdening the engineering team with administrative work.

Learn More About SOC 2 Compliance Automation

For a broader look at how to handle evidence for controls beyond change management, see our guide on automating SOC 2 evidence collection, including how to handle access reviews and infrastructure monitoring. You may also find these relevant:

• Do You Actually Need a vCISO for SOC 2? - Why AI is replacing the $10k/month consultant
• The Bootstrapped Founder's Guide to SOC 2 - How to get SOC 2 done without a massive budget