Mitigating Two Difficult SOC 2 Type II Controls With Practical Evidence

SOC 2 Type II · Security Controls · Evidence · Access Reviews · Change Management · Compliance

OC 2 Type II is not only about having policies. It is about proving that controls operated effectively over a defined audit period. That is why many organizations struggle: the control may exist, but the evidence is inconsistent, incomplete, or difficult to explain.

Two of the most challenging SOC 2 Type II control areas are periodic access reviews and production change management. Both require discipline across teams, and both generate evidence auditors expect to see clearly.

Control 1: Periodic Access Reviews

Access reviews are difficult because user access changes constantly. Employees join, move roles, leave the company, receive temporary access, or accumulate privileges over time. If reviews are informal, organizations may find excessive permissions only when an auditor asks for evidence.

A strong access review control should define:

• Which systems are in scope
• How often reviews occur
• Who performs the review
• What reviewers must check
• How exceptions are remediated
• How completion is evidenced

For example, a company may define that all privileged access to production systems, cloud consoles, identity providers, source code repositories, and ticketing systems is reviewed quarterly by system owners.

To mitigate this control, start with a system inventory. Each system should have an owner, access source, role list, and review frequency. Then create a repeatable access review workflow.

A practical workflow could look like this:

1. Export users and roles from the identity provider and critical applications.
2. Send each system owner a review task.
3. Require the owner to mark each user as approved, remove, or investigate.
4. Track removals as remediation actions.
5. Attach final exports, approvals, and removal evidence to the review record.

The strongest evidence includes the user list reviewed, timestamped reviewer approval, identified exceptions, remediation tickets, and proof that access was removed where required.

Example evidence package:

• Okta administrator export for Q2
• GitHub organization member export for Q2
• AWS IAM privileged role export for Q2
• Completed access review task signed by each system owner
• Jira tickets for removed access
• Screenshots or logs showing access removal
• Management summary showing review completion rate and overdue exceptions

The key is consistency. Auditors do not want a heroic access review done once before the audit. They want to see that the review happened on schedule and that exceptions were handled.

Control 2: Production Change Management

Change management is difficult because engineering teams move quickly. Emergency fixes, infrastructure changes, feature releases, configuration updates, and database migrations may all affect production. If changes are approved inconsistently or lack testing evidence, SOC 2 Type II testing becomes painful.

A strong change management control should define:

• What counts as a production change
• Required approvals
• Testing expectations
• Emergency change process
• Rollback requirements
• Evidence retained for each change

For example, a company may define that all production code, infrastructure, and configuration changes must be linked to a ticket, reviewed through pull request approval, tested before deployment, and traceable to a deployment record.

To mitigate this control, avoid manual approval theater. Use the engineering workflow as the evidence source.

A practical workflow could look like this:

1. Every production change starts with a ticket describing the business or technical reason.
2. The change is implemented through a pull request.
3. The pull request requires peer review and passing automated checks.
4. Deployment is performed through CI/CD, not manually from a developer laptop.
5. The deployment record links back to the pull request and ticket.
6. Emergency changes require retrospective approval within a defined timeframe.

Example evidence package:

• Jira ticket describing the requested change
• Pull request showing code review approval
• CI/CD test results showing successful checks
• Deployment log showing who deployed and when
• Release notes or change summary
• Rollback plan or reference to standard rollback procedure
• Emergency change retrospective approval, if applicable

A good example control statement would be:

“All production changes are documented in the ticketing system, reviewed through pull requests, tested through automated CI/CD checks, and deployed through approved pipelines. Emergency changes are reviewed retrospectively within two business days.”

This gives auditors a clear path to test the control. They can sample changes and verify that each one has a ticket, approval, testing, and deployment evidence.

Making These Controls Easier Over Time

The best way to reduce SOC 2 Type II pain is to make evidence a byproduct of normal work.

Access reviews should create evidence automatically through review tasks, exports, approvals, and remediation records. Change management should create evidence naturally through tickets, pull requests, CI/CD logs, and deployment history.

When evidence is collected after the fact, SOC 2 becomes stressful. When evidence is built into the workflow, SOC 2 becomes manageable.

The goal is not to satisfy an auditor once. The goal is to build controls that are reliable enough to operate every month without panic.