If you’re evaluating an insurance premium billing vendor for your health plan, you’ll see compliance certifications prominently featured in every sales deck: SOC 2 Type II, PCI-DSS, etc. The certifications are real—but what they actually mean, what they cover, and what they leave out is often less clear.
This post aims to explain to health plan leaders, IT teams, and compliance officers what a couple of common certifications mean. We’ll walk through what two common certifications actually test, what questions to ask about scope and coverage, and how to think about shared responsibility when working with a vendor handling sensitive payment and member data.
SOC 2 Type II: The Security Baseline
What SOC 2 Type II Actually Is
SOC 2 (Service Organization Control 2) is an auditing standard developed by the American Institute of CPAs (AICPA). A SOC 2 Type II report evaluates whether a company’s controls are designed effectively and operating consistently over time—typically a minimum of six months.
The framework is built around five Trust Services Criteria:
- Security (required for all SOC 2 audits): protection against unauthorized access
- Availability: system uptime and operational performance
- Processing Integrity: accurate, complete, and timely processing
- Confidentiality: protection of sensitive information beyond what’s covered by security
- Privacy: collection, use, retention, and disclosure of personal information
Not all vendors pursue all five criteria. Security is mandatory, but the others are optional. This matters because many vendors advertise “SOC 2 Type II” but only cover security—not availability, processing integrity, confidentiality, or privacy.
What SOC 2 Doesn’t Tell You
SOC 2 reports are scoped. The audit examines specific systems and processes that the vendor chooses to include. A SOC 2 Type II report for “the billing platform” might not cover the vendor’s customer support systems, their data warehouse, or third-party tools used for analytics or payment processing.
You also won’t find details about incident response times, vulnerability remediation benchmarks, or specific security practices in the marketing materials. Those details live inside the actual SOC 2 report—which is confidential and requires an NDA to access.
Questions to Ask: Which Trust Services Criteria are covered in your SOC 2 audit? Does the scope include all systems interacting with our data, or just the core billing platform? Can we review the actual SOC 2 report (under NDA) before signing?
PCI-DSS: Payment Security Standards
What PCI-DSS Actually Is
PCI-DSS (Payment Card Industry Data Security Standard) is a set of security requirements for any organization that stores, processes, or transmits credit card information. Compliance is mandatory if you accept card payments—not optional.
There are four compliance levels, determined by transaction volume. Most billing vendors fall into Level 1 (over 6 million transactions annually) or Level 2 (1–6 million transactions). The requirements are similar, but Level 1 requires an annual on-site assessment by a Qualified Security Assessor (QSA), while Level 2 can use a Self-Assessment Questionnaire (SAQ).
The Sub-Processor Question
Most insurance premium billing vendors don’t process card payments directly—they use a payment gateway or payment processor as a third party. This creates an important question: Is the payment processor the vendor’s sub-processor, or your direct vendor?
If the processor is the vendor’s sub-processor, the vendor is responsible for their PCI compliance. If the processor is a separate vendor with whom you have a direct contract, responsibility for ensuring PCI compliance falls to you. This distinction affects liability, audit scope, and who owns the relationship with the payment gateway.
Questions to Ask: What is your PCI-DSS compliance level, and when was your most recent assessment? Is your payment gateway vendor acting as your sub-processor, or will we have a direct contractual relationship with them? Can you provide your Attestation of Compliance (AOC)?
Multi-Tenant SaaS vs. Dedicated Environments
A question that doesn’t get asked enough: does the vendor operate a single multi-tenant environment where all clients share infrastructure, or does each client get a dedicated instance?
Multi-tenant environments are more common and typically more cost-effective. The challenge is that security testing—like penetration testing—gets complicated when infrastructure is shared. If your organization requires annual pen testing, you need to understand whether the vendor’s architecture allows it, whether they conduct their own pen tests that cover your data, and whether you’ll be allowed to engage your own third-party firm.
Dedicated or client-specific environments avoid this problem but come with higher costs and potentially longer implementation timelines.
Questions to Ask: Is your platform multi-tenant or client-specific? If multi-tenant, how do you handle client-requested penetration testing? Do you conduct your own penetration tests, and can we review the results?
Shared Responsibility: Who Owns What?
Certifications tell you what the vendor has implemented. They don’t tell you what you are still responsible for.
In a vendor relationship, security and compliance are shared responsibilities. The vendor is responsible for the security of the platform itself, including infrastructure, application code, patching, access controls, and encryption. You are responsible for how you configure and use it. Items like user permissions, data you upload, integration security, and incident response are your responsibility.
Key areas where responsibility is often unclear:
- User access management: who grants and revokes user permissions?
- Data retention and deletion: who ensures member data is purged on schedule?
- Incident response: who detects, investigates, and reports security incidents?
- Integration security: who secures the API keys, SFTP credentials, and file transfers between systems?
- Backup and disaster recovery: what’s the vendor’s responsibility vs. yours?
Questions to Ask: How are responsibilities documented in the contract or BAA? What happens if there’s a security incident—what’s your role vs. ours in detection, response, and notification?
Beyond Certifications: Operational Security Markers
Certifications are a baseline. They tell you a vendor passed an audit at a point in time. What they don’t tell you about the vendor’s daily operations.
Operational security markers matter more than most buyers realize. These are the ongoing practices that determine whether a vendor stays secure over time:
- Patching benchmarks: How quickly do they patch critical vulnerabilities? What’s the SLA for high/medium/low severity issues?
- Uptime and availability: What are their uptime commitments, and what happens when they’re breached?
- Vulnerability management: Do they conduct regular vulnerability scans? How are findings prioritized and remediated?
- Change management: How do they handle emergency changes vs. planned releases? What’s the approval process?
Vendors who can answer these questions specifically with numbers, timelines, and documented processes are operating differently from vendors who deflect to certifications.
Questions to Ask: What are your patching SLAs for critical, high, and medium severity vulnerabilities? What operational security metrics do you track and report to clients (uptime, incident response times, vulnerability remediation)?
The Bottom Line
SOC 2 and PCI-DSS certifications are important. What separates strong vendors from weak ones is how they operate beyond the audit. That includes how clearly they document shared responsibility, how quickly they patch vulnerabilities, how seriously they take operational security, and how transparent they are when you ask hard questions.
The vendors worth working with don’t hide behind certifications. They explain what the certifications cover, what isn’t covered, and what you’re still responsible for. Documentation is provided. They share metrics. They answer the operational questions.
Certifi’s health insurance premium billing and payment solutions help healthcare payers improve member satisfaction while reducing administrative costs.
