7 Things to Fix Before Your SOC 2 Auditor Sees Them

Preparing for a SOC 2 audit is not just about having security policies, tools, and controls in place. You also need to prove that those controls are properly designed, implemented, followed, and particularly for a SOC 2 Type II audit — operating effectively over time.

That is where many organizations discover problems.

A security policy may exist but no longer reflect actual processes. Access may be restricted, but nobody regularly reviews privileged accounts. An incident response plan may look complete on paper but has never been tested.

Finding these issues during your SOC 2 audit readiness process gives you time to correct them. Finding them when the auditor asks for evidence can lead to additional remediation work and potentially audit exceptions.

So, before the audit begins, check these seven common areas.

What Does a SOC 2 Auditor Look For?

SOC 2 examinations evaluate controls relevant to one or more of the AICPA Trust Services Criteria: Security, Availability, Processing Integrity, Confidentiality, and Privacy.

Security is included in every SOC 2 examination, while the other categories are selected according to the organization's services, commitments, and system scope.

However, SOC 2 audit preparation is not simply about creating a checklist of security technologies.

Auditors need evidence supporting the controls included in the examination. Depending on the control, this may include policies, access reviews, tickets, approvals, system configurations, logs, risk assessments, vendor reviews, training records, incident documentation, or other evidence showing that the organization actually follows its defined processes.

This is why a SOC 2 readiness assessment should look beyond whether a control technically exists.

The important question is:

Here are seven areas worth checking before your auditor does.

1. Access Rights That Nobody Has Reviewed Recently

Access management is one of the first areas organizations should examine during SOC 2 audit readiness.

Over time, permissions accumulate.

Employees change roles. Contractors finish projects. Temporary administrator privileges become permanent. Service accounts remain active long after the system that required them has changed.

The result can be unnecessary or excessive access.

Before the audit, review:

• active users and service accounts;

• privileged and administrator accounts;

• access to production environments;

• cloud and SaaS permissions;

• terminated-user access;

• role changes;

• MFA implementation;

• periodic access review records.

The important issue is not simply whether your company follows the principle of least privilege. You also need evidence showing how access is granted, approved, reviewed, modified, and removed.

For example, if your policy states that privileged access is reviewed quarterly, you should be able to demonstrate that those reviews actually occurred.

A documented policy without corresponding SOC 2 audit evidence can create an avoidable gap.

2. Controls That Work but Leave No Evidence

One of the most frustrating SOC 2 compliance gaps is also one of the easiest to prevent: a control is being performed, but there is no reliable evidence of it.

Imagine that your engineering team reviews every production change before deployment.

Good.

But where are the approvals recorded?

If decisions happen in calls or private messages and there is no retained record connecting the approval to the change, demonstrating consistent operation of the control becomes much harder.

The same problem can occur with:

• access reviews;

• employee onboarding and offboarding;

• security awareness training;

• vulnerability management;

• backups;

• incident management;

• change approvals;

• vendor reviews;

• risk assessments.

During SOC 2 evidence collection, verify that every important control has an identifiable evidence source.

Ask three simple questions:

If your team cannot answer all three consistently, address the process before the audit begins.

3. Security Policies That Don't Match Reality

Another common problem is the gap between documented policies and actual operations.

A company may have created its security policies months ago during the early stages of its compliance program. Since then, the infrastructure, tools, employees, vendors, or internal processes may have changed.

The documentation did not.

For example, a policy might state that:

• access reviews occur quarterly, while the team performs them annually;

• a particular security tool is used, although it has been replaced;

• incidents are reported through a process employees no longer follow;

• backups are tested according to a schedule that is no longer relevant;

• terminated accounts are disabled through a process that has since been automated differently.

  
  

This is why SOC 2 documentation requirements should not be approached as a one-time paperwork exercise.

Before the audit, compare policies and procedures with what employees actually do.

Update outdated documentation, clarify responsibilities, remove processes that no longer exist, and make sure control descriptions correspond to the real environment.

Do not create a perfect process on paper.

Document the process you can consistently operate and demonstrate.

4. Change Management That Happens Outside the Process

Fast-moving SaaS and technology companies deploy frequently. That makes change management an especially important part of SOC 2 audit preparation.

The problem is rarely that organizations make changes.

The problem is that some changes bypass the defined process.

A developer may push an urgent fix without the normal approval. Infrastructure may be modified directly in production. A change may have a pull request but no documented review. Emergency changes may occur without subsequent review.

Before your SOC 2 audit, examine whether your SOC 2 change management controls consistently cover:

• code reviews;

• testing;

• approvals;

• production deployments;

• infrastructure changes;

• segregation of duties where applicable;

• emergency changes;

• documentation and traceability.

Then compare the documented process with a sample of actual changes.

If your policy says every production change requires approval, but the technical workflow allows developers to bypass that requirement, you have a gap worth fixing before audit testing begins.

5. Vendor Risk Management That Ends With a Vendor List

Knowing which third parties your organization uses is not the same as managing third-party risk.

Cloud providers, payment processors, CRM systems, identity platforms, analytics tools, development services, and other vendors may process or have access to sensitive company or customer information.

A strong SOC 2 vendor management process therefore needs more than a spreadsheet containing vendor names.

Depending on the risk associated with the provider, your organization may need to document:

• what service the vendor provides;

• what systems or data it can access;

• the risk associated with the relationship;

• security and privacy considerations;

• due diligence performed before onboarding;

• available assurance reports or certifications;

• contractual security requirements;

• periodic reassessment;

• what happens when the relationship ends.

Pay particular attention to critical vendors.

If your organization depends heavily on a third party but has never evaluated the security implications of that dependency, include it in your SOC 2 readiness assessment.

Third-party risk should be managed as a process, not treated as a one-time questionnaire.

6. An Incident Response Plan That Has Never Been Tested

Having an incident response document is important.

Knowing whether it works is more important.

A security incident is a poor time to discover that employees do not know whom to contact, escalation paths are outdated, responsibilities overlap, or critical contact information is missing.

Review your SOC 2 incident response plan before the audit and make sure it reflects your current organization and technology environment.

Check whether it clearly defines:

• incident identification and reporting;

• roles and responsibilities;

• severity levels;

• escalation procedures;

• containment and recovery;

• internal and external communication;

• documentation requirements;

• post-incident review.

Then test it.

A tabletop exercise can help determine whether the process works outside the document.

Give the relevant employees a realistic scenario, for example, compromised administrator credentials or suspected customer data exposure and walk through the response.

Who makes the first decision? Who investigates? Who needs to be informed? Where are actions documented? What happens if a critical person is unavailable?

The exercise often exposes gaps that reviewing the policy alone will not reveal.

7. A Risk Assessment That Exists Only for Compliance

A SOC 2 risk assessment should represent the risks your organization actually faces.

It should not simply be a generic spreadsheet created because an audit requires one.

As your organization changes, its risk profile changes as well.

You may have:

• launched a new product;

• migrated infrastructure;

• adopted a new cloud provider;

• integrated new vendors;

• introduced AI tools;

• expanded into another market;

• changed how customer data is processed;

• added remote employees or contractors.

Your risk assessment should reflect significant changes to the business and its environment.

Before the audit, review whether identified risks are current and whether they are connected to appropriate controls and remediation activities.

For each significant risk, you should be able to explain:

What could happen?

What assets or processes would be affected?

How likely and significant is the risk?

What controls reduce it?

Who owns the risk?

Is additional treatment required?

A useful risk assessment should guide security decisions not just satisfy a compliance task.

How to Know If You Are Ready for a SOC 2 Audit

A good SOC 2 readiness checklist should answer more than “Do we have this control?”

For every control in scope, verify:

Design: Does the control address the relevant risk and requirement?

Implementation: Has the control actually been implemented?

Ownership: Does someone clearly own the control?

Operation: Is the control being performed as defined?

Evidence: Can you prove that it happened?

Consistency: Has the process been followed consistently during the relevant period?

This distinction becomes particularly important when preparing for a SOC 2 Type II audit, where the examination addresses not only the suitability of control design but also their operating effectiveness over a specified period.

A readiness review before the formal examination gives your organization an opportunity to identify SOC 2 control deficiencies, collect missing evidence, correct inconsistent processes, and complete remediation before they become audit findings.

SOC 2 Audit Readiness Checklist

Before moving into the audit, confirm that:

• access and privileged accounts have been reviewed;

• terminated and transferred users have appropriate access removed or modified;

• controls have identifiable owners;

• required control activities are being performed on schedule;

• evidence exists for the relevant control activities;

• security policies match actual processes;

• production changes are documented and approved according to your defined process;

• critical vendors have been appropriately assessed;

• the incident response process is current and has been tested where appropriate;

• the risk assessment reflects the current environment;

• identified gaps have owners and remediation plans.

If several of these questions are difficult to answer, your organization may benefit from additional SOC 2 audit preparation before beginning the formal examination.

What to Do If You Find SOC 2 Compliance Gaps

Finding gaps during preparation is not necessarily a sign that your compliance program has failed.

It is the purpose of readiness work.

Prioritize each issue according to risk and its relevance to the controls in scope. Then determine:

• what needs to change;

• who owns the remediation;

• what evidence needs to be generated or retained;

• when remediation must be completed;

• whether the corrected control needs time to operate before the examination period.

Avoid trying to solve every issue by creating more documentation.

Sometimes the correct solution is a technical configuration change. Sometimes it is a new approval workflow, clearer ownership, better evidence retention, employee training, or a change to an existing process.

The goal of SOC 2 remediation is to create controls that are both effective and sustainable.

Prepare for SOC 2 Before the Auditor Finds the Gaps

The best time to discover a SOC 2 problem is before the formal audit starts.

A structured SOC 2 readiness assessment can identify gaps between your policies, controls, technical environment, evidence, and day-to-day operations while there is still time to remediate them.

ESKA Security helps organizations prepare for SOC 2 by analyzing current security and compliance practices, identifying gaps, developing the required policies and procedures, and supporting the implementation of necessary improvements.

If you are preparing for your first SOC 2 examination or need help closing existing compliance gaps, explore ESKA Security's SOC 2 Compliance services.

The goal should not be to make your environment look compliant for the auditor. It should be to build controls that work and have the evidence to prove it.

FAQ: SOC 2 Audit Preparation

What are the most common SOC 2 audit findings?

Common issues can involve access management, missing or inconsistent control evidence, outdated policies, change management, third-party risk management, incident response, and risk assessment. The specific findings depend on the organization's environment, controls, scope, and audit testing.

What evidence is needed for a SOC 2 audit?

The required evidence depends on the controls being tested. Examples may include access review records, configuration evidence, change tickets and approvals, training records, risk assessments, incident records, vendor assessments, logs, policies, and other documentation demonstrating that controls operated as described.

How should you prepare for a SOC 2 audit?

Start with a SOC 2 readiness assessment. Define the scope, map applicable controls, review their design and implementation, identify control owners, verify that processes operate consistently, collect supporting evidence, and remediate gaps before formal audit testing.

What is the difference between SOC 2 Type I and Type II?

A SOC 2 Type I examination addresses the description of the service organization's system and the suitability of the design of controls as of a specified date. A SOC 2 Type II examination additionally addresses whether those controls operated effectively throughout a specified period.

How can you avoid SOC 2 audit exceptions?

There is no way to guarantee that an examination will have no exceptions. However, organizations can reduce preventable issues through early readiness assessment, consistent control operation, evidence collection, regular access and vendor reviews, current documentation, and remediation of identified gaps before the audit period.

When should you start SOC 2 audit preparation?

Preparation should begin early enough to define scope, implement missing controls, remediate identified gaps, and especially for a Type II examination — allow controls to operate and generate appropriate evidence during the relevant period.