What Is a Compliance Audit? Types and Process

What Is a Compliance Audit? Types, Process, and Preparation

A compliance audit is a formal, evidence-based review that confirms whether an organization is actually doing what its policies, contracts, and applicable regulations require. The auditor (internal staff, an external firm, or a regulator) tests a sample of controls, interviews staff, and reads supporting evidence, then issues a written opinion or report. If the controls work as designed, the report is clean. If they do not, the report flags the gaps and the organization fixes them.

This guide explains what a compliance audit is, the types you are most likely to face, how the process actually unfolds week by week, what auditors look for, what they cost, and how to prepare without wasting money. It is written for SaaS founders, CTOs, and operations leads who are facing their first formal audit.

What is a compliance audit, in plain terms

A compliance audit answers one question: are you doing what you say you are doing?

The auditor compares your stated policies and required controls (the "design") against the actual evidence of those controls running in the wild (the "operation"). Design without operation is a finding. Operation without design is also a finding. Both must hold.

There are three core moving parts in any compliance audit:

1. The framework or law being audited against (SOC 2, HIPAA, ISO 27001, PCI DSS, NIST 800-53, GDPR, internal policy, contract terms)
2. The audit period, either a single point in time or a window of months
3. The evidence package the auditor sees (policies, screenshots, logs, ticket records, training records, configuration exports)

Outside of healthcare, you will not face a government auditor for the most common cybersecurity frameworks. SOC 2 and ISO 27001 audits are conducted by private firms (CPAs and certification bodies). HIPAA audits are conducted by the Department of Health and Human Services Office for Civil Rights when triggered by a breach or complaint. PCI DSS validation is performed by Qualified Security Assessors. The mechanics differ, the principle is identical: independent testing of controls against a defined standard.

Compliance audit vs internal audit vs assessment

These three terms get used interchangeably, which causes a lot of confusion in procurement conversations. They are not the same.

A compliance audit is performed by an independent third party (or a sufficiently independent internal team) and produces a formal opinion or attestation. SOC 2 reports, ISO 27001 certifications, and PCI DSS Reports on Compliance are all compliance audits.

An internal audit is performed by the organization's own audit function, often as preparation for an external audit or as ongoing assurance to the board. Most ISO 27001 programs require at least one internal audit per year before the certification audit. See our ISO 27001 internal audit guide for the mechanics.

A compliance assessment (or readiness assessment) is informal, gap-focused, and produces a list of issues to fix. There is no opinion or certification at the end. Most teams do an assessment 3 to 6 months before the real audit so they can fix gaps in private rather than have them documented in an audit report.

The pattern most companies follow: assessment → fix gaps → internal audit → external compliance audit.

Types of compliance audits

Different audits exist because different stakeholders ask different questions. The most common types in the cybersecurity and SaaS space:

SOC 2 audit (what is a compliance audit for SaaS?)

A SOC 2 audit, performed by a CPA firm, evaluates a service organization against the AICPA Trust Services Criteria. It produces a SOC 2 Type 1 report (point-in-time control design) or a SOC 2 Type 2 report (control operation over a 3 to 12 month window). SOC 2 Type 2 is the most commonly requested compliance artifact in B2B SaaS procurement. See the full SOC 2 compliance guide for the framework, and how long does a SOC 2 audit take for the timeline.

ISO 27001 certification audit (what is a compliance audit for ISO?)

An ISO 27001 certification audit is performed by an accredited certification body in two stages: Stage 1 (documentation review) and Stage 2 (operational testing). A successful Stage 2 produces an ISO 27001 certificate valid for three years, with surveillance audits annually. See our ISO 27001 certification guide for the full process.

HIPAA audit (what is a compliance audit in healthcare?)

A HIPAA audit can be triggered by a breach notification or by an OCR proactive audit. There is no scheduled annual HIPAA audit. The audit reviews Privacy Rule, Security Rule, and Breach Notification Rule compliance and can result in corrective action plans, monetary penalties, or settlements. Most healthcare SaaS companies preempt this by commissioning a third-party HIPAA assessment annually. See the HIPAA compliance pillar for the full framework.

PCI DSS audit — what is a compliance audit for card processors

PCI DSS audits depend on merchant level. Level 1 merchants (over 6 million card transactions per year) require an annual on-site assessment by a Qualified Security Assessor producing a Report on Compliance. Levels 2 to 4 use a Self-Assessment Questionnaire. See our PCI DSS compliance pillar and PCI DSS SAQ guide for the mechanics.

NIST 800-53 / FedRAMP audit — what is a compliance audit for fed contractors

For federal contractors and cloud service providers selling to the US government, NIST 800-53 audits and FedRAMP authorizations are performed by accredited Third Party Assessment Organizations. These are heavier, more rigorous, and typically take 12 to 18 months. See our FedRAMP authorization guide and NIST 800-53 controls breakdown.

Internal compliance audit (what is a compliance audit, in-house)

An internal audit is performed by your own audit function (or an outsourced internal audit firm) against your internal policies and selected external requirements. It produces findings and recommendations for management, not a formal external opinion.

Vendor compliance audit — what is a compliance audit for vendors

When you ask a vendor for evidence (a SOC 2 report, an ISO certificate, a security questionnaire), you are conducting a vendor compliance audit. Most modern compliance programs include an annual review of every critical vendor's compliance posture.

What auditors actually look at

Across every framework, auditors test a similar set of evidence. The labels differ but the underlying activity does not. Specifically:

• Policies and procedures — written, version-controlled, last-reviewed dates inside the audit period
• Risk assessment — most frameworks require a documented annual risk analysis
• Access reviews — quarterly or semi-annual reviews of who has access to what production system
• Change management — every code or infrastructure change must trace through a ticket, code review, and approval
• Vendor management — list of critical vendors, BAAs / DPAs / security questionnaires on file
• Training records — every employee completed required security training, with date and content
• Incident response — at least one tabletop or real incident with documentation through the audit period
• Backup and recovery testing — at least one documented restore test
• Vulnerability management and patching — scan reports, ticket trail of remediation, SLA evidence
• Logging and monitoring — log retention duration, alert response examples
• Physical and environmental controls — for any office or data center environment
• HR controls — onboarding/offboarding checklists, background checks where required

The evidence is usually pulled from your ticketing system (Jira, Linear), HRIS, identity provider (Okta, Google), endpoint manager, GRC platform, and source code platform. The first audit is heavy because you are building the evidence pipeline. The second is dramatically lighter.

How a compliance audit actually unfolds

A SOC 2 Type 2 audit, the most common audit a SaaS company will face, is a useful template. Other audits compress or extend the same steps.

Phase 1 — Pre-audit (months 1 to 6)

Build the program. Write policies, implement controls, train staff, run an internal risk assessment, and (often) buy a GRC platform. This is the longest phase and the place where most teams underspend. See how to build a compliance program from scratch for the playbook.

Phase 2 — Readiness assessment (weeks 1 to 4)

A consultant or auditor does a dry run. Output: a gap list. You fix the gaps before the real audit window starts.

Phase 3 — Audit window (3 to 12 months for Type 2, single point for Type 1)

The auditor observes your controls operating. You collect evidence continuously. Most modern teams use a GRC platform (Vanta, Drata, Sprinto, Secureframe) to automate evidence collection so this phase does not become a full-time job.

Phase 4 — Fieldwork (4 to 8 weeks)

The auditor pulls samples, requests evidence, schedules interviews, and tests each control. You respond to evidence requests inside their portal. Most fieldwork happens in a 2 to 4 week intensive window followed by a few weeks of follow-up.

Phase 5 — Reporting (2 to 6 weeks)

The auditor drafts the report, you review for factual corrections, the auditor finalizes. The final report lands and you can share it with prospects under NDA.

Phase 6 — Annual cycle

For SOC 2 Type 2, ISO 27001, and PCI DSS, the cycle repeats every year. The second cycle is dramatically easier because the evidence pipeline already exists.

Compliance audit cost ranges

Audit costs vary widely based on scope, company size, and chosen auditor. Rough year-one ranges:

The audit fee itself is usually 10 to 30 percent of total program cost. Internal labor, GRC tooling, penetration testing, and remediation work consume the rest. For more granular figures see SOC 2 audit cost and ISO 27001 certification cost.

How to prepare for a compliance audit

The first audit is the hardest because you are building everything from scratch. A practical preparation sequence:

Step 1 — Pick the framework and the auditor

Match the framework to the buyer requirement, not to what is intellectually appealing. Run a short auditor RFP (3 to 5 firms), check references, compare scope and price, and pick.

Step 2 — Run a gap assessment

Either internally (if you have the expertise) or with a consultant. The output is a prioritized gap list with owners and target dates.

Step 3 — Close the gaps

Write or update policies, implement missing technical controls, run training, complete the risk assessment, and put the change management workflow in place. This is where most of the calendar time goes.

Step 4 — Wire up evidence collection

Connect your GRC platform to your identity provider, code repository, HRIS, endpoint manager, and ticketing system. Configure the controls library to your scope. Test that evidence is flowing before the audit window starts. See our Vanta vs Drata vs Secureframe comparison for tooling guidance.

Step 5 — Run the internal audit

For ISO 27001 this is mandatory. For SOC 2 it is strongly recommended. The internal audit catches issues before the external auditor does and gives the external auditor confidence in your program maturity.

Step 6 — Manage the audit window with discipline

For SOC 2 Type 2, the audit window is 3 to 12 months. Every control must operate every day during that window. One missed access review or one untracked production change becomes a finding.

Step 7 — Run the external fieldwork tightly

Assign an internal owner for evidence requests. Set an SLA (e.g. respond inside 48 business hours). Use the auditor's portal, not email, so requests do not get lost. Hold a weekly status call during fieldwork.

What happens when you fail

Failing an audit rarely means losing the certification or the customer. It usually means the auditor identifies findings, you submit a corrective action plan, and you remediate. The flavors of failure differ by framework.

For SOC 2, the auditor can issue an unqualified opinion (clean), a qualified opinion (some controls did not operate as designed), an adverse opinion (rare, fundamental control failures), or a disclaimer (auditor could not gather enough evidence). Most first audits land with one or two minor exceptions. See what happens if you fail a SOC 2 audit for the recovery path.

For ISO 27001, the certification body documents major and minor non-conformities. Major non-conformities block certification until they are remediated. Minor non-conformities can be corrected in a documented action plan without blocking the certificate.

For HIPAA, an OCR investigation can produce a corrective action plan, a resolution agreement, civil monetary penalties (up to $2.13 million per violation category per year), or in extreme cases criminal referral. Most cases resolve through corrective action plans and settlements.

For PCI DSS, a failed assessment usually results in a remediation period and a re-test. Persistent non-compliance can result in card brand fines and increased transaction processing fees.

Common mistakes that derail audits

Three mistakes we see repeatedly.

The first is starting the audit window before the controls are in place. If a control was implemented in month 3 of a 6-month audit window, the auditor only has 3 months of evidence to test. Auditors will often note this and may require an extended observation period.

The second is treating the audit as a one-time event rather than a continuous program. Annual audit cycles repeat. Teams that disband the compliance program after the first clean report face a much harder second audit.

The third is buying tooling without owning the program. GRC platforms are powerful but they do not write your policies, run your risk assessment, or sit in the auditor interview. A platform without an owner produces a heavy evidence trail of half-complete controls.

Frequently asked questions

What is the difference between a compliance audit and a financial audit?

A financial audit reviews financial statements for accuracy under GAAP or IFRS. What is a compliance audit by contrast? It reviews adherence to a specific regulatory or contractual framework (SOC 2, HIPAA, ISO 27001, PCI DSS, GDPR). The two are separate engagements performed by different specialists, even though both can be performed by the same firm.

How long does a compliance audit take?

How long does a compliance audit take depends on the framework, but to ground the answer: SOC 2 Type 1 takes 8 to 12 weeks of fieldwork plus reporting. SOC 2 Type 2 has a 3 to 12 month observation window plus 8 to 12 weeks of fieldwork. ISO 27001 Stage 1 plus Stage 2 is 4 to 8 weeks of fieldwork on top of a 6 to 12 month implementation. PCI DSS Level 1 is typically 4 to 12 weeks of QSA work. FedRAMP can take 12 to 18 months total.

Who can perform a compliance audit?

SOC 2 must be performed by a licensed CPA firm. ISO 27001 must be performed by an accredited certification body. PCI DSS Level 1 must be performed by a Qualified Security Assessor. HIPAA assessments can be performed by any qualified consultant, though OCR audits are performed by HHS itself.

What is the difference between a SOC 2 Type 1 and Type 2 audit?

Type 1 evaluates control design at a single point in time. Type 2 evaluates control operation over a window of 3 to 12 months. Type 2 is the version enterprise buyers actually want.

Can a compliance audit be remote?

Yes. What is a compliance audit physically? In 2026, almost all SOC 2, ISO 27001, and HIPAA audits are now conducted remotely with screen-share and document portals. Some PCI DSS Level 1 assessments and FedRAMP assessments still include on-site components for physical and environmental control testing.

How often do compliance audits repeat?

SOC 2 Type 2 is annual. ISO 27001 has a 3-year cycle (initial certification, two surveillance audits, then re-certification). PCI DSS Level 1 is annual. HIPAA assessments are typically annual. FedRAMP requires continuous monitoring and an annual assessment.

Do small companies need a compliance audit?

Need is driven by buyers and regulators, not company size. A 10-person startup signing its first hospital deal needs HIPAA. A 10-person SaaS landing a fintech enterprise customer needs SOC 2. If no buyer or regulator is asking, a formal audit is premature.

The bottom line

A compliance audit is a structured, evidence-based test of whether your organization is doing what its policies and obligations require. The framework, auditor, and timeline differ, but the core mechanics (policies, evidence, sampling, opinion) are constant.

The companies that pass cleanly do three things well: they pick the framework that matches their buyer requirement (not a wishlist), they build the program 4 to 6 months before the audit window opens, and they treat the audit as a continuous program rather than a sprint. Everything else is detail.

For the framework-by-framework breakdown, see our pillar guides: SOC 2, HIPAA, ISO 27001, PCI DSS, NIST CSF, and the cybersecurity compliance pillar that ties them together. External reference: the AICPA SOC 2 overview and the HHS HIPAA enforcement page are useful primary sources.

About the author: James Mitchell is a Compliance and Security Analyst with eight-plus years of experience helping SaaS, healthcare, and fintech companies prepare for SOC 2, HIPAA, ISO 27001, PCI DSS, and FedRAMP audits. He has guided more than 60 audit engagements end-to-end.