What compliance testing actually requires — and how to prepare for audits without the last-minute panic

Compliance isn’t a checkbox. It’s a continuous state of readiness that requires ongoing testing, documentation, and evidence collection.

Most software teams discover this the hard way — during an audit, when an enterprise client asks for a SOC2 report, or when a healthcare partner requires HIPAA documentation before signing a contract. By then, the work that should have been happening for months needs to happen in weeks.

This guide covers the compliance landscape for US companies — which frameworks apply to which industries, what each framework actually requires from a testing perspective, and how to build a compliance testing process that makes audits straightforward rather than stressful.

Compliance requirements by industry

The compliance framework that applies to your product depends on what your product does with data, which industries it serves, and where your users are located. Here’s the landscape:

Industry	Primary frameworks	Key testing requirements	Consequence of non-compliance
Healthcare	HIPAA, HITECH	PHI access controls, audit logs, encryption	Up to $1.9M per violation category per year
Finance/Fintech	SOC2, PCI-DSS, SOX	Financial data controls, access management	Fines, loss of payment processing ability
SaaS (enterprise)	SOC2 Type II	Security, availability, confidentiality controls	Lost enterprise deals, reputational damage
E-commerce	PCI-DSS, CCPA	Payment data handling, consumer privacy	Fines, card brand penalties
Any (EU customers)	GDPR	Data processing consent, breach notification	Up to 4% of global annual revenue
Government contractors	FedRAMP, FISMA	Federal security controls	Loss of government contracts

Most SaaS companies in 2026 need to care about at least two frameworks: SOC2 (for enterprise sales) and GDPR (if any of their users are in the EU). Healthcare and fintech add HIPAA and PCI-DSS respectively. Understanding which frameworks apply is the first step — the second is understanding what each actually requires.

HIPAA compliance testing for healthcare applications

HIPAA (Health Insurance Portability and Accountability Act) applies to any software that creates, receives, maintains, or transmits Protected Health Information (PHI). This includes electronic health records, patient portals, health apps that store medical data, billing systems, and any platform used by healthcare providers or insurers.

HIPAA compliance is not a certification — there’s no HIPAA audit firm that issues a certificate. It’s a self-assessed compliance state that must be documented and demonstrable if the Department of Health and Human Services (HHS) investigates. This means your compliance evidence needs to be thorough and current.

The Security Rule: what to test

HIPAA’s Security Rule covers electronic PHI (ePHI) and requires implementation of administrative, physical, and technical safeguards. The testing requirements fall into the technical safeguard category:

• Access controls: test that only authorized users can access ePHI. Every access path — direct database access, API endpoints, administrative interfaces, background jobs — must be covered. Unauthorized access attempts must be logged and blocked.
• Audit controls: HIPAA requires logging of all activity on systems that contain ePHI. Test that audit logs capture user ID, timestamp, action taken, and data accessed. Verify logs cannot be modified or deleted by regular users. Test log retention — HIPAA requires 6 years.
• Integrity controls: test that ePHI cannot be altered or destroyed in an unauthorized manner. Verify checksums or digital signatures on PHI records. Test that unauthorized modification attempts are detected and logged.
• Transmission security: test that ePHI transmitted over networks is encrypted. Verify TLS is enforced on all endpoints that handle PHI. Test that encrypted transmission can’t be downgraded by an attacker.
• Automatic logoff: test that sessions handling PHI automatically terminate after a defined period of inactivity. Verify that terminated sessions cannot be resumed without re-authentication.

The Privacy Rule: what to test

The Privacy Rule covers the use and disclosure of PHI, not just electronic PHI. Testing implications:

• Minimum necessary: verify that API responses return only the PHI fields necessary for the specific function. A billing query shouldn’t return complete clinical records.
• Authorization verification: test that PHI disclosure flows verify patient authorization where required. Third-party integrations that receive PHI need documented business associate agreements (BAAs) and authorization verification.
• Patient rights: test that patients can access their own records, request amendments, and obtain accounting of disclosures. These are regulatory requirements, not optional features.

HIPAA testing in practice

HIPAA compliance testing requires a different mindset than functional testing. You’re not just verifying that features work — you’re verifying that every access to PHI is controlled, logged, and authorized. The most common HIPAA testing gaps:

• Background jobs that access PHI without logging — batch processes, scheduled reports, data exports
• Administrative interfaces that bypass the access controls applied to regular users
• Legacy API endpoints that predate the compliance requirements and weren’t updated when controls were added
• Third-party integrations where PHI is sent to vendors without BAAs or proper authorization verification

A practical HIPAA testing approach: map every data flow that touches PHI — from where it enters the system to where it’s stored, processed, transmitted, and deleted. Test each flow against the Security and Privacy Rule requirements. Document the test results. This documentation is your compliance evidence.

HIPAA testing case study

A patient engagement platform — a SaaS product that connected healthcare providers with patients for appointment scheduling, messaging, and care coordination — engaged TestMatick for HIPAA compliance testing before onboarding their first hospital system client.

The testing revealed three significant gaps that the development team hadn’t identified:

First, the appointment reminder system sent SMS messages containing patient names and appointment details. While the messages were sent over encrypted channels, the content itself constituted PHI transmission to a third-party SMS provider that had no Business Associate Agreement in place. The fix required both a BAA with the SMS provider and a content review to minimize PHI in message text.

Second, the audit logging system captured user access events but missed background job activity entirely. A nightly data sync job that pulled patient records from connected EHR systems was executing without any audit trail. This was a direct HIPAA Security Rule violation — all PHI access must be logged regardless of whether it’s a human or automated process.

Third, session timeout was configured at 8 hours — far exceeding the 15-minute standard required by most healthcare organizations’ security policies and recommended by HIPAA guidance. The development team had set the timeout for user convenience without recognizing the compliance implication.

All three were fixed before the hospital system client completed their security review. The fixes required one week of development work. Discovering them post-contract, during a client security audit, would have required significantly more — plus the risk of contract termination.

SOC2 Type II testing requirements

SOC2 (System and Organization Controls 2) is the de facto compliance standard for SaaS companies selling to enterprises. Unlike HIPAA, SOC2 is assessed by independent auditors who issue a formal report. A SOC2 Type II report covers a period of time (typically 6-12 months) and verifies that your controls were operating effectively throughout that period — not just at the point of audit.

This is the critical distinction between Type I and Type II. SOC2 Type I verifies that controls exist at a point in time. SOC2 Type II verifies that controls operated effectively over a period. Enterprise buyers care about Type II — it’s evidence of sustained compliance, not just compliance on audit day.

The Trust Service Criteria

SOC2 is organized around five Trust Service Criteria (TSC). Most companies pursue the Security criterion as a minimum; additional criteria depend on what your customers care about:

Trust Service Criteria	What it covers	Key controls to test
Security (CC)	Protection against unauthorized access	Access controls, encryption, vulnerability management, incident response
Availability (A)	System available as committed	Uptime monitoring, disaster recovery, capacity planning
Processing Integrity (PI)	Processing complete, valid, accurate	Error handling, data validation, processing controls
Confidentiality (C)	Confidential info protected	Data classification, access restrictions, encryption
Privacy (P)	Personal info collected, used properly	Consent management, data retention, subject rights

What SOC2 testing actually looks like

SOC2 auditors don’t just review documentation — they test controls. They pull sample evidence: access logs, change management records, security scan results, incident response records, employee training completions. If your controls exist only on paper but aren’t consistently applied, Type II auditors find it.

Testing requirements for the Security criterion specifically:

• Logical access controls: test that access provisioning and deprovisioning processes work correctly. Verify that terminated employees lose access promptly. Test that least-privilege principles are enforced — users have only the permissions they need.
• Vulnerability management: demonstrate regular vulnerability scanning. Test that identified vulnerabilities are remediated within defined SLAs. Auditors want evidence of both scanning and remediation.
• Change management: test that deployments go through change management processes. Code reviews, approved changes, deployment logs. Auditors sample deployments to verify they followed the process.
• Incident response: test your incident response procedures. Tabletop exercises, documented procedures, evidence of previous incident handling. Auditors verify that incidents are detected, responded to, and documented.
• Availability monitoring: demonstrate uptime monitoring and alerting. Test that alerts fire correctly. Show historical uptime data. For Availability TSC, demonstrate disaster recovery capabilities.

Building toward SOC2 Type II

SOC2 Type II requires 6-12 months of evidence collection before the audit period. This means you need to start the compliance process 6-12 months before you need the report. Common mistakes that delay SOC2 certification:

• Starting evidence collection too late — the audit period must cover sufficient time to demonstrate consistent controls
• Inconsistent control application — controls that work most of the time but have documented exceptions create audit findings
• Documentation gaps — controls that exist but aren’t documented are treated as controls that don’t exist
• Scope creep — adding systems to the audit scope late in the process extends the timeline

The most underestimated part of SOC2 preparation is change management evidence. Auditors sample deployments to verify they followed your documented change management process — code review, approval, deployment log. Teams that deploy informally, without documented approvals, fail this control consistently. The fix isn’t difficult, but it requires changing deployment habits months before the audit period starts.

Access reviews are another common finding source. SOC2 requires periodic reviews of who has access to what systems — typically quarterly. The review itself is simple: pull a list of users and their permissions, have a manager verify it’s correct, document the review. The problem is that teams often do the review once before the audit and claim quarterly reviews they didn’t actually perform. Auditors check dates. Build the quarterly access review into your calendar as a recurring process, not a pre-audit scramble.

A practical SOC2 preparation timeline: Month 1-2, gap assessment and control documentation. Month 3-4, remediate gaps and begin evidence collection. Month 5-14, audit observation period with consistent control operation and evidence capture. Month 15-17, auditor fieldwork and report issuance. This assumes starting from a reasonably mature security program — teams with minimal existing controls should add 3-6 months.

GDPR compliance for US companies with EU customers

GDPR (General Data Protection Regulation) applies to any company that processes personal data of EU residents — regardless of where the company is located. If you have EU users, GDPR applies to you, whether you’re based in New York or anywhere else.

The enforcement reality in 2026: GDPR enforcement has increased significantly since the regulation took effect. The largest fines have exceeded €1 billion. US companies have been fined — not just EU companies. If you have meaningful EU user traffic, GDPR compliance is not optional.

GDPR testing requirements

• Consent management: test that consent is obtained before data processing where required. Verify consent records are stored with timestamp, user ID, and consent version. Test that withdrawing consent actually stops processing — not just flags an account.
• Data subject rights: test that users can access their data (Subject Access Request), correct inaccurate data, delete their data (Right to Erasure), and export their data (Data Portability). Each of these must work correctly within the regulatory timeframes (typically 30 days).
• Data minimization: verify that your application collects only the data it needs. Test that optional fields are genuinely optional and not required by the system even if not required by the UI.
• Data retention: test that data is deleted or anonymized when retention periods expire. Automated deletion jobs should be tested for completeness — verify that all storage locations (databases, backups, logs, analytics systems) are covered.
• Breach notification: test your breach detection and notification processes. GDPR requires notification to supervisory authorities within 72 hours of discovering a breach. Verify that your monitoring would detect a breach and that notification procedures are documented and tested.
• Third-party data processors: verify that all third parties who receive EU personal data have Data Processing Agreements (DPAs) in place. Test that data transfer mechanisms to non-EU countries (Standard Contractual Clauses, adequacy decisions) are properly implemented.

The Right to Erasure: what testing actually covers

The Right to Erasure (Article 17 GDPR) is one of the most technically complex GDPR requirements to implement and test correctly. When a user requests deletion of their data, ‘deletion’ must be complete — across all storage systems, not just the primary database.

Testing Right to Erasure requires mapping every location where user data exists: primary database, read replicas, caches, search indexes, analytics platforms, data warehouses, backup systems, logs, and any third-party systems that received the data. A deletion request that wipes the primary database but leaves user data in a search index or analytics platform is a GDPR violation.

Test the erasure process end-to-end: submit a deletion request through the documented process, verify deletion from each storage location on your data map, verify that the deletion is irreversible (data can’t be restored from backup after the retention period), and verify that the user receives confirmation within the regulatory timeframe. Document each test with timestamps and evidence — this documentation demonstrates due diligence if the erasure is ever challenged.

GDPR vs CCPA

US companies with California users also need to comply with CCPA (California Consumer Privacy Act) and its amendment CPRA. CCPA covers similar ground to GDPR — consumer rights to access, delete, and opt out of sale of personal data — but with different specifics. Testing both simultaneously is more efficient than treating them as separate compliance projects: build the data subject rights infrastructure once, configure it to meet both regulations’ requirements.

Penetration testing vs compliance testing

Compliance testing and penetration testing are related but distinct disciplines. Understanding the difference prevents both over-investment and under-investment in security testing.

Compliance testing verifies that specific, predefined controls are in place and working. It’s structured, documented, and repeatable. The test scenarios are defined by the compliance framework. The output is evidence that requirements are met.

Penetration testing simulates an attacker attempting to compromise your system using any means available. It’s creative, adversarial, and scenario-driven. The output is a list of vulnerabilities found, their severity, and remediation recommendations.

The relationship: compliance testing is necessary but not sufficient for security. A system can pass all compliance tests and still have significant vulnerabilities that a skilled attacker would find. Penetration testing finds what compliance testing misses. Most compliance frameworks (HIPAA, SOC2, PCI-DSS) recommend or require periodic penetration testing in addition to compliance testing — because the framework authors understand this distinction.

Practical recommendation: compliance testing should be continuous — integrated into your development and release process. Penetration testing should be periodic — annually at minimum, before major releases, and after significant architectural changes. The two complement each other; neither replaces the other.

A common scenario that illustrates why both are necessary: a healthcare SaaS company completed their SOC2 Type II audit successfully — all controls passed, report issued, enterprise deals closed. Six months later, a penetration test found a critical vulnerability in their password reset flow that allowed account takeover without knowing the current password. The vulnerability wasn’t covered by any SOC2 control because SOC2 doesn’t test specific vulnerability classes — it tests whether a vulnerability management program exists. The program existed and was working. The vulnerability existed too. Compliance testing confirmed the process; penetration testing found the gap the process missed.

Audit preparation checklist

Whether you’re preparing for a SOC2 audit, a HIPAA assessment, or an enterprise security review, the preparation process has common elements:

90 days before audit

• Confirm audit scope — which systems, which Trust Service Criteria, which time period
• Review control documentation — verify all controls are documented, current, and accurate
• Run internal gap assessment — test controls against audit requirements before auditors do
• Identify and remediate gaps — prioritize by audit risk, not by technical preference
• Verify evidence collection processes — confirm logs, access reviews, and change records are being captured

30 days before audit

• Complete access reviews — verify current user access lists match what’s documented
• Run vulnerability scans and remediate findings — auditors will ask for recent scan results
• Complete employee security training — document completion for all in-scope employees
• Review incident log — ensure all incidents are documented with response and resolution
• Verify backup and recovery procedures — test restoration process, document results

During audit

• Assign a single point of contact for auditor requests — prevents inconsistent responses
• Respond to evidence requests promptly — delays extend the audit timeline
• Don’t volunteer information beyond what’s asked — answer questions accurately and completely, not expansively
• Document all auditor findings immediately — creates a remediation record

The compliance testing mindset

Compliance testing is not a project with an end date. It’s an ongoing practice that becomes part of how your engineering team works — the same way automated testing became part of how software teams deploy code.

The companies that handle compliance audits smoothly aren’t the ones with the most expensive compliance programs. They’re the ones that built compliance into their regular development process early enough that evidence collection is automatic, controls are consistently applied, and gaps are found internally rather than by auditors.

The alternative — treating compliance as an audit-time scramble — is more expensive, more stressful, and more likely to result in findings that delay certification or, worse, delay enterprise deals that depend on it. A SOC2 finding that surfaces in an auditor’s report is a public record of a control failure. The same finding surfaced in an internal gap assessment is a ticket in your backlog.

The practical starting point for most SaaS companies: identify which frameworks apply to your product and your customers, run an internal gap assessment against the requirements, and build evidence collection into your existing development and operations processes. You don’t need a dedicated compliance team to start — you need clarity about what’s required and the discipline to apply controls consistently.

For healthcare and fintech companies, the stakes are higher and the requirements more specific. HIPAA violations can exceed a million dollars per violation category per year. GDPR fines have reached into the billions for major non-compliance. The cost of building a compliance testing program is a fraction of the cost of a single significant enforcement action.

The question isn’t whether compliance testing is worth the investment. For any company handling sensitive data, selling to regulated industries, or pursuing enterprise customers, it’s table stakes. The question is whether you build the program deliberately — before you need it — or reactively, when an audit, a client requirement, or a regulatory action forces the issue.

Preparing for a compliance audit?

TestMatick has helped US companies prepare for HIPAA assessments, SOC2 Type II audits, and GDPR compliance reviews since 2009. If your team is facing an upcoming audit or building compliance infrastructure for the first time, that’s a conversation worth having.

-> Schedule Compliance Audit — testmatick.com