Menu
If you’re pursuing SOC 2 right now, the pressure usually shows up before the audit does. A prospect asks for a report, procurement sends a security review, or leadership wants a timeline for closing an enterprise deal. A soc 2 internal audit is a self-assessment your team runs against the AICPA Trust Services Criteria to evaluate whether your controls are properly designed, operating as intended, and supported by evidence before an external CPA firm examines them. It matters because the external auditor won’t accept good intentions, informal habits, or undocumented processes. They will look for controls that exist, run consistently, and leave a reliable trail of proof.
For most SaaS teams, that’s where reality sets in. The problem usually isn’t that nothing exists. The problem is that access reviews happened but weren’t saved, change approvals live in scattered tools, vendors were reviewed informally, and nobody can show the same control operating consistently over time. A solid internal audit catches that before it becomes an external exception.
What a SOC 2 Internal Audit Actually Is
A SOC 2 internal audit is an internal control validation process performed before the formal SOC 2 examination. It checks your environment against the relevant Trust Services Criteria, tests whether controls are designed appropriately, and verifies whether those controls are operating in practice. The purpose isn’t to issue a report. It’s to find gaps while you still control the timeline.
That distinction matters. An external SOC 2 audit is an attestation performed by a licensed CPA firm. An internal audit is your chance to pressure-test the same control environment under lower stakes. If the external audit is the exam, the internal audit is the full rehearsal with evidence, testing, and remediation.
The teams that get value from this treat it as an operating discipline, not a one-time readiness task. SOC 2 guidance from Hyperproof describes an effective internal audit cycle as five steps: define scope, perform a readiness or gap assessment, test design and operating effectiveness, collect and retain evidence in a structured audit trail, and remediate gaps before external fieldwork begins. That sequence is practical because it mirrors how auditors think.
Practical rule: If a control owner can describe a control but can’t produce evidence for it quickly, treat that control as unproven.
For someone pursuing SOC 2, this matters because internal audit reduces avoidable surprises. It tells you whether your policies connect to real activity, whether your control owners understand their responsibilities, and whether your evidence will survive auditor scrutiny. It also forces a harder but necessary question: are you building a compliance program that will still work after the first report is issued?
Scoping Your Audit and Selecting Trust Services Criteria
Scope mistakes are expensive. If you scope too narrowly, the report may not satisfy customer expectations. If you scope too broadly, your team creates evidence obligations it can’t sustain.
SOC 2 always starts with one fixed point. Security is mandatory in every SOC 2 engagement, while Availability, Processing Integrity, Confidentiality, and Privacy are optional and should be selected based on your service commitments and risk profile, as summarized in SOC 2 audit scoping guidance. For internal audit planning, that means your first job is to define what your system does, what customer promises you make, and which criteria you can support with mature controls.
Start with your customer commitments
A practical scoping exercise starts with a small set of questions:
- What service are you auditing: The production SaaS application, supporting infrastructure, internal admin tools, and key vendors should be clearly named.
- What do customers rely on: If you promise uptime commitments, Availability may be relevant. If you store customer secrets or regulated business data, Confidentiality may be necessary.
- What can you defend with evidence: A criterion only belongs in scope if you can map it to real controls, real owners, and reproducible records.
A lot of first-time teams add criteria because they sound impressive. That usually backfires. If you include Availability, for example, your internal audit needs to verify disaster recovery procedures, incident handling, monitoring, and related records. If those controls are immature, you’ve increased burden without increasing credibility.
For cloud-heavy environments, it also helps to review broader critical cloud audit insights before finalizing scope, especially if your platform depends on deployment pipelines, shared infrastructure, or multiple managed services.
Keep the scope tight enough to test well
A strong scope document should identify:
- In-scope systems: Production applications, cloud accounts, identity systems, ticketing platforms, code repositories, and logging tools.
- In-scope people and teams: Engineering, security, IT, support, HR, and any outsourced operators who perform control activities.
- In-scope criteria: Security plus only the optional criteria that reflect actual commitments and actual risk.
- Exclusions: Anything intentionally outside the report boundary.
If you want a second check on that decision process, this SOC 2 scope determination guide is useful for comparing scope choices before you lock in the audit plan.
Over-scoping doesn’t make a report stronger. It usually makes exceptions more likely.
This matters for someone pursuing SOC 2 because scope determines everything that follows: which controls you document, which teams you involve, which evidence you collect, and how much audit friction you’ll create later.
Mapping Controls to Criteria and Designing Tests
Once scope is set, the work becomes more concrete. You need to translate broad Trust Services Criteria into specific controls your company performs, then define how you’ll test them.
The best internal audits don’t start from policy PDFs. They start from operational reality. What system enforces access? Who approves production changes? Where is vendor review documented? Which team tracks incidents? Then they map that activity to the relevant criteria and point of focus.
Write controls the way auditors test them
A useful control statement includes four parts:
| Element | What to include |
|---|---|
| Control objective | What risk the control addresses |
| Owner | The team or role responsible |
| Procedure | What happens, where, and how often |
| Evidence | What artifact proves it happened |
For example, if you map a control to logical access, a weak version is: “Engineering reviews access periodically.”
A testable version is: “The engineering manager reviews privileged access to production systems quarterly in Okta and AWS, documents approvals and removals in Jira, and retains the review artifact in the compliance repository.”
That difference matters because your internal audit will test both design effectiveness and operating effectiveness.
Separate design testing from operating testing
Design testing asks whether the control, if followed, would satisfy the criterion. Operating testing asks whether the control ran as described during the audit period.
Here’s the simplest way to understand it:
- Design effectiveness: Is the control written clearly enough, assigned properly, and capable of addressing the risk?
- Operating effectiveness: Did the owner perform it consistently, on schedule, and leave evidence behind?
A lot of teams fail internal audit here because they confuse policy with execution. A signed access control policy doesn’t prove access reviews happened. A change management standard doesn’t prove pull requests were reviewed before deployment.
When the control touches authentication or authorization, technical specificity matters. If your platform uses delegated access, token-based flows, or third-party identity, your control narrative should reflect how that architecture works. For teams tightening those descriptions, a practical OAuth2 guide can help clarify the system behavior behind access-related controls.
A control map should let another person understand the risk, the procedure, the owner, and the evidence without needing a meeting.
For someone pursuing SOC 2, the audit gains credibility at this point. If you can’t map controls cleanly to criteria and define how they’ll be tested, your external auditor will end up doing that thinking for you, and that usually means more back-and-forth, more follow-ups, and more stress.
Executing Tests and Collecting Evidence
This is the part that exposes whether your program is real. Testing is where a control owner says, “Yes, we do quarterly access reviews,” and the internal audit answers, “Show me the review, the date, the approver, the resulting actions, and where the record is stored.”
Good evidence is specific, time-bound, and tied to the control. Weak evidence is informal, incomplete, or impossible to reproduce later. The external auditor will care less about what people remember and more about what your records prove.
What good evidence looks like
Here are common examples that hold up better in a soc 2 internal audit:
- Access review controls: Exported user lists from Okta, Google Workspace, Azure AD, or AWS. Reviewer signoff. Ticket references for removed users. Retained copies of the reviewed population.
- Change management controls: GitHub pull requests, peer approvals, linked Jira tickets, CI/CD deployment logs, and production release records.
- Incident response controls: Incident tickets, Slack or Teams incident channel transcripts exported to a record, post-incident review notes, and follow-up tasks.
- Vendor management controls: Approved vendor inventory, review notes, contract security terms, and copies of vendor assurance documents.
- Security awareness controls: LMS completion records, onboarding assignments, and exception follow-up for incomplete training.
The evidence itself needs structure. This SOC 2 evidence collection guide is a useful reference for building an evidence library that control owners can maintain throughout the year.
Build an audit trail, not a screenshot pile
The common failure isn’t lack of activity. It’s poor documentation. As noted earlier in the article, weak documentation can cause an auditor to treat a control as ineffective even when the activity occurred. That’s why every test should have a consistent package:
- The control description
- The test procedure
- The evidence artifact
- The reviewer’s conclusion
- Any exception noted
Hyperproof’s SOC 2 guidance emphasizes that internal audit works best when evidence is collected and retained in a structured audit trail, and it warns against treating the exercise as a one-time checklist in place of ongoing monitoring through the audit window.
Here’s a practical evidence table you can use internally.
Example SOC 2 Evidence Collection
| TSC Reference | Example Control | Internal Audit Test Procedure | Required Evidence Artifact |
|---|---|---|---|
| CC6.3 | Quarterly privileged access review for production systems | Inspect the most recent completed review, confirm reviewer identity, verify any removals were tracked and completed | Access export, dated review record, approval notes, removal ticket |
| CC8.1 | Production changes require documented approval before deployment | Select a sample of recent production changes and inspect whether approval occurred before release | Pull request record, linked ticket, approval history, deployment log |
| CC7.2 | Security incidents are logged and escalated through the incident process | Review incident register and inspect one completed incident for classification, response, and closure documentation | Incident ticket, response notes, communications log, closure record |
| CC9.2 | Critical vendors are subject to security review before approval | Inspect a recent vendor onboarding and verify security review evidence exists before use | Vendor review checklist, approval record, assurance document copy |
| CC1.2 | New hires acknowledge security policies during onboarding | Select recent hires and confirm policy acknowledgment was completed and retained | HRIS onboarding record, acknowledgment log, policy version record |
For internal network exposure or segmentation-related controls, teams sometimes supplement audit preparation with technical validation such as securing client networks with pentesting, especially when they need stronger evidence around internal attack paths or privilege boundaries.
If evidence lives only in somebody’s inbox or memory, it doesn’t belong in your control environment.
This matters for SOC 2 because Type 2 readiness depends on sustained execution, not isolated examples. Internal testing and evidence collection are what turn a control set into something an auditor can rely on.
Documenting Findings and Managing Remediation
A mature internal audit always produces findings. If yours doesn’t, the more likely explanation is that the review was shallow.
The useful question isn’t whether issues exist. It’s whether you can classify them correctly, assign ownership fast, and close them without losing the audit timeline. A missed access review, an undocumented vendor approval, or a policy that references a process nobody follows are all valuable findings if you handle them cleanly.
Log findings with enough detail to act
Each finding should include:
- What failed: The control didn’t run, ran late, or lacked support.
- Why it matters: State the risk in operational terms.
- Who owns the fix: Name a person or role, not a department.
- What happens next: Immediate correction, process change, and retest requirement.
A useful finding entry reads like this:
Quarterly privileged access review for the AWS production environment was not completed within the expected period. Risk: inappropriate access may remain undetected. Root cause: the primary owner was unavailable and no delegate was assigned. Remediation: complete the overdue review, assign backup ownership, and update the procedure.
That level of detail helps distinguish control failure from evidence failure. Those are not the same thing. If a review happened but the record wasn’t retained, you may have a documentation issue. If nobody performed the review at all, you have an operating issue. The remediation path should reflect that difference.
A short explainer on exception handling is worth watching before you formalize your process:
Remediate in a way auditors can follow
Remediation should be visible and testable. The easiest way to lose control of this phase is to fix issues in conversations instead of systems.
Use a tracker in Jira, Asana, Linear, or your GRC tool with these fields:
| Field | Why it matters |
|---|---|
| Finding ID | Keeps references consistent across reviews |
| Related control | Connects the issue to the audit universe |
| Root cause | Prevents cosmetic fixes |
| Owner | Makes accountability clear |
| Due date | Keeps remediation tied to audit timing |
| Status | Shows whether the issue is open, in progress, or retested |
| Retest result | Confirms closure with evidence |
A practical point here: not every issue deserves the same urgency. Repeated minor documentation misses in one control area can signal weak ownership. A single missing screenshot usually doesn’t. Trending exceptions upward during infrastructure changes deserve close attention because they may indicate the control no longer fits the way the system now operates.
Presenting self-identified and remediated findings is not a weakness. It shows management oversight, operational honesty, and a functioning control environment. For someone pursuing SOC 2, that matters because auditors trust programs that can detect and correct their own failures.
Preparing the Handoff to Your External Auditor
The handoff should feel like transferring a well-maintained file, not launching a rescue effort. By the time you reach this point, the auditor should be able to understand your scope, your controls, your evidence set, and your open issues without rebuilding the program from scratch.
What to package
Your handoff folder or compliance platform should contain:
- Scope documentation: The defined system boundary, in-scope criteria, and key exclusions.
- Control narratives: Each control, owner, frequency, and evidence source.
- Testing records: Internal test procedures, results, exceptions, and retest notes.
- Evidence repository: Final artifacts organized by control and period.
- Remediation log: Open and closed issues with status.
- Key contacts: Control owners and the internal point person for auditor requests.
If you’re still selecting an audit firm, teams sometimes use comparison platforms such as SOC2Auditors to review auditor options, timelines, and practical fit before the external engagement starts.
Match your internal cycle to the report cycle
A useful planning benchmark is to assess all in-scope controls at least annually, with some controls reviewed more often on a monthly or quarterly cadence, according to SOC 2 internal audit planning guidance. That annual rhythm lines up with the fact that SOC 2 Type 2 reports are typically valid for 12 months and then re-evaluated in the same guidance, which is why strong internal audit programs mirror the external reporting cycle instead of operating as one-off projects.
One more trade-off is worth stating clearly. Historical benchmark data summarized by CBIZ shows that internal audit involvement in SOC engagements declined to 5.2% of reports in 2024 from 8% the prior year in the 2024 SOC benchmark study analysis. For companies pursuing SOC 2, the practical takeaway is simple: don’t assume internal audit work will reduce external testing unless your documentation, workpapers, and evidence quality are strong enough for the auditor to rely on confidently.
A good soc 2 internal audit makes the external audit predictable. It gives your auditor a clean starting point, gives your team fewer surprises, and gives leadership a more realistic path to report issuance. Most importantly, it connects internal discipline directly to SOC 2 audit readiness. That’s the real purpose of the exercise. Not to complete a checklist, but to prove your controls can stand up to formal examination without last-minute scrambling.