Dedicated Teams for Regulated Industries: HIPAA, SOC 2, and GDPR Compliance

A vendor lists "HIPAA compliant, SOC 2 certified, GDPR ready" on the first page of their pitch deck. The buyer accepts this at face value. Six months into the engagement, the client's SOC 2 Type II auditor asks for the vendor's subprocessor list, their access review documentation, their breach notification runbook. The vendor produces a marketing one-pager. The auditor does not accept marketing one-pagers.

This is The Artifact Gap.

The distance between what a vendor claims about compliance and what they can actually produce when an auditor, regulator, or enterprise client asks for evidence. Most dedicated team vendors have compliance claims. A smaller number have compliance artifacts. The difference matters in two specific scenarios: when the client's own compliance posture is being audited (because the vendor's gaps become the client's findings) and when a regulator investigates a breach (because contractual compliance language doesn't substitute for actual technical safeguards).

For dedicated teams working on systems covered by SOC 2 Trust Services Criteria, HIPAA Security Rule, GDPR Article 28, or DORA — which is most healthcare, fintech, insurance, and EU-facing product work — The Artifact Gap is a structural risk the client inherits. The size of the gap determines whether a compliance event at the vendor becomes a noisy footnote or an existential business problem.

SOC 2: What Actually Has to Exist

SOC 2 isn't a law. It's a framework administered by the AICPA, documented in the Trust Services Criteria. A SOC 2 Type II report — the one that matters for enterprise procurement — describes how a service organization's controls operate over a period (typically 6-12 months) and whether those controls are designed appropriately and operating effectively.

For dedicated team engagements, SOC 2 Common Criteria CC6 is the most directly relevant set of controls. Secureframe's walkthrough of CC6 covers CC6.1 through CC6.8 — logical and physical access controls. CC6.6 explicitly addresses third-party access, which is what a dedicated team is. The practical requirements the vendor must have documented and operating:

• Access provisioning. Every engineer gets least-privilege access, granted through a documented approval workflow, not a Slack message.
• Access review. Quarterly review of who has access to what, with documentation of the review process and outcomes.
• Access revocation. When an engineer leaves the team, access is revoked within a defined window (typically 24 hours) with evidence.
• MFA enforcement. All production system access requires multi-factor authentication, logged.
• Privileged access monitoring. Admin-level access is logged and reviewed.

What The Artifact Gap looks like at CC6: the vendor says "all engineers use MFA," and that's true, but there's no evidence of access review, no record of offboarded engineers' access revocation, and no policy document describing the provisioning workflow. In a Type II audit, this fails. The specific 2026 SOC 2 changes tracked by Konfirmity show continued emphasis on formal risk assessments, API security, microsegmentation, and continuous monitoring — the documentation bar is rising, not falling.

Cost of getting this right on the vendor side: $30,000-$150,000 annually per Secureframe's compliance cost analysis for audit and ongoing maintenance. Vendors that haven't invested in this can't produce a Type II report on request, which means the client can't use them for regulated work regardless of what the marketing page says.

HIPAA: The BAA Is Necessary But Not Sufficient

HIPAA is law. Vendors handling Protected Health Information (PHI) are Business Associates under the HIPAA Security Rule, which mandates administrative, physical, and technical safeguards plus a Business Associate Agreement (BAA) between the covered entity and the business associate.

The HIPAAVault guide to BAA requirements details the mandatory BAA components: permitted uses of PHI, breach notification timelines, subcontractor flow-down requirements, termination provisions, and specific technical safeguards. This document is necessary. It is not sufficient.

The non-obvious part — and where The Artifact Gap usually sits for HIPAA — is what Aptible's BAA analysis calls out directly: a signed BAA doesn't make an application HIPAA compliant. The BAA is a legal agreement establishing liability, not a technical control. Compliance requires the technical safeguards in 45 CFR 164.312 actually operating in production:

• Access control. Unique user IDs, emergency access procedures, automatic logoff, encryption of ePHI at rest.
• Audit controls. Hardware, software, and procedural mechanisms recording activity in systems containing ePHI.
• Integrity controls. Protection against improper alteration or destruction of ePHI.
• Transmission security. Encryption of ePHI in transit across networks.

Ulam Labs' 2025 engineering guide to HIPAA names a failure mode worth flagging: BAA coverage gaps for third-party tools the dedicated team adopts without explicit PHI consideration. Datadog, Sentry, Segment, Slack — if any of these touches ePHI in the course of dedicated team work and doesn't have a BAA in place, the client's HIPAA posture has a hole that nobody negotiated.

The verification question for HIPAA: can the vendor produce a documented list of every SaaS tool that touches ePHI in their environment, with BAAs in place for each, alongside their technical safeguards documentation? Vendors that can are actually HIPAA-operational. Vendors that can't have a signed BAA and a compliance claim that won't survive a real investigation.

GDPR Article 28: The DPA Nobody Reads

GDPR Article 28 governs the controller-processor relationship, which is what most dedicated team engagements create. The official Article 28 text on GDPR-Info is mandatory reading for any engagement involving EU personal data. The article requires a binding written contract — a Data Processing Agreement — covering specific terms:

• Processing only on documented instructions. The vendor doesn't decide what to do with the data; the client does.
• Duty of confidence. Personnel handling the data are committed to confidentiality.
• Security measures. Appropriate technical and organizational measures per Article 32.
• Subprocessor controls. No subprocessors without prior written authorization; flow-down of DPA terms.
• Data subject rights assistance. The vendor helps the client respond to access, erasure, and portability requests within required windows.
• Breach notification. The vendor notifies the client "without undue delay" — typically interpreted as within 24-72 hours.
• Audit rights. The client can audit the vendor's compliance.
• Data deletion. At the end of the engagement, the vendor returns or deletes personal data.

The Enzuzo guide to Article 28 DPAs covers the penalties: up to EUR 10M or 2% of global revenue for processor-side violations. The Article 28 DPA is a mandatory artifact; the question The Artifact Gap asks is whether the vendor has a DPA template ready that meets Article 28's requirements, or whether they have to scramble to build one when the client asks.

For engagements involving cross-border data transfers — EU data processed by a team sitting outside the EEA — the vendor also needs to handle Standard Contractual Clauses (SCCs) per the European Commission's 2021 update. The post-Schrems II reality is that SCCs alone aren't always enough; transfer impact assessments may be required. Vendors without a clear cross-border transfer story are a GDPR risk the client inherits.

A related note: the UK ICO's guidance on controller-processor contracts covers UK GDPR specifics after Brexit. For UK clients, the UK-specific DPA terms apply on top of the broader framework.

DORA: The New Layer for EU Financial Services

The Digital Operational Resilience Act (DORA) became enforceable in January 2025 for EU financial services entities and their ICT providers. Dedicated teams working on systems for EU banks, insurers, investment firms, and other regulated financial entities are now directly in scope as "ICT third-party service providers."

DORA is the newest layer, and the one most vendors haven't absorbed yet. The contract-level requirements that change the shape of a deal:

• Contractual provisions. DORA prescribes specific contract terms covering service levels, data sovereignty, encryption key management, subcontracting transparency, audit and inspection rights, and exit strategies.
• ICT risk management framework. The vendor has to demonstrate an ICT risk management framework aligned with DORA's requirements, not just assert one.
• Incident reporting. Major ICT-related incidents at the vendor must be reported to the client within windows tight enough to support the client's own regulatory reporting obligations.
• Exit strategy. Contracts must include a documented plan for orderly exit from the ICT provider, including data portability and ongoing support windows.

For dedicated team engagements on EU financial services work, the DORA provisions are not optional additions to the MSA — they're structural requirements that change what "compliant" means. Vendors without a documented DORA readiness posture aren't a fit for this work.

The Verification Checklist

Four artifacts separate vendors with actual compliance from vendors with compliance claims. Ask for them before signing, not after.

• SOC 2 Type II report. Type I is a snapshot; Type II is the report with teeth. Scope should include the services the vendor is providing to you. Look specifically for the CC6 controls and any noted exceptions or qualifications.
• HIPAA BAA template and technical safeguards documentation. Generic BAAs are table stakes. What distinguishes operational HIPAA vendors is the supporting documentation — subprocessor BAA list, encryption-at-rest and in-transit evidence, audit log samples, access control policies.
• GDPR Article 28 DPA template and subprocessor list. The DPA should be ready-to-sign, not something the vendor will draft when you ask. The subprocessor list should be current, with DPA flow-downs in place for each.
• Penetration test summary from the last 12 months. Independent pen test findings and remediation evidence. SOC 2 increasingly expects this; DORA requires it for financial services. Vendors without recent pen test evidence are operating in a compliance blind spot.

One more verification principle: these artifacts should be produceable within 48 hours of a request. Vendors that need weeks to produce a current Type II report or an up-to-date subprocessor list don't actually have an operational compliance program — they have a collection of documents that get updated when a specific client asks.

Honest Boundary

Compliance frameworks evolve continuously. Several caveats worth flagging:

• Vertical specifics matter. FINRA, PCI-DSS, FedRAMP, ISO 27001, HITRUST, and industry-specific regulations (NERC CIP for power, FISMA for government) layer additional requirements on top of the frameworks in this post. A dedicated team working on government systems faces FedRAMP; one working on payment processing faces PCI-DSS. This post covers the most broadly relevant frameworks, not the exhaustive per-vertical list.
• AI regulation is in flux. The EU AI Act creates mandatory requirements based on AI system risk level. US state-level AI laws are emerging. Dedicated teams building AI features for EU clients need to understand AI Act classification and documentation requirements — a fast-moving area where today's guidance becomes stale quickly.
• Breach response varies. The frameworks above specify notification windows, but actual breach response involves legal coordination, potential law enforcement engagement, customer communications, and operational remediation. This post doesn't substitute for incident response planning.
• SOC 2 is meaningful but not universal. IAPP's guidance reminds buyers that SOC 2 and ISO 27001 reports are useful for vetting processors but cannot be taken at face value to signify GDPR compliance. Each framework covers different things; stacking them doesn't eliminate gaps between them.
• Country-specific data localization rules. Russia, China, and several other jurisdictions require personal data of their citizens to be stored locally. Dedicated teams sitting in those jurisdictions, or working on data for those jurisdictions, face additional constraints not covered in this post.

The frameworks covered here are necessary conditions for compliant dedicated team work in regulated industries, not sufficient ones. Buyer compliance programs should treat vendor compliance as a layered checklist, not a single box.

Need help verifying whether a vendor's compliance posture is operational or marketing? Talk to an engineer.

---

Claims don't survive audits. Artifacts do.

Frequently Asked Questions

What compliance frameworks apply to a dedicated development team in regulated industries?

Four overlap for most regulated dedicated team engagements: SOC 2 Type II (audited controls for trust services criteria, especially CC6 third-party access), HIPAA (Business Associate Agreement plus technical safeguards per 45 CFR 164.312 for any work touching PHI), GDPR Article 28 (Data Processing Agreement for EU personal data, with SCCs for cross-border transfers), and DORA (enforceable January 2025 for EU financial services ICT providers, adding contract-level risk management and exit strategy requirements).

Is a signed BAA enough for HIPAA compliance with a dedicated team?

No. A Business Associate Agreement establishes legal liability, not technical control. HIPAA compliance requires the technical safeguards in 45 CFR 164.312 actually operating: access control with unique user IDs, audit controls logging ePHI activity, integrity protections, and transmission encryption. It also requires BAAs with every third-party tool that touches PHI in the dedicated team's environment — Datadog, Sentry, Slack, or similar if any of them sees PHI.

What does GDPR Article 28 require from a dedicated team vendor?

A binding Data Processing Agreement covering: processing only on documented instructions, personnel confidentiality, Article 32 security measures, subprocessor controls with written authorization, data subject rights assistance, breach notification without undue delay (typically 24-72 hours), audit rights, and data return or deletion at engagement end. For cross-border transfers outside the EEA, Standard Contractual Clauses plus transfer impact assessments per post-Schrems II guidance. Penalties reach EUR 10M or 2% of global revenue.

How do I verify a dedicated team vendor's compliance claims?

Request four artifacts with a 48-hour turnaround expectation: current SOC 2 Type II report with CC6 controls visible, HIPAA BAA template plus subprocessor BAA list and technical safeguards documentation, GDPR Article 28 DPA template plus current subprocessor list, and a penetration test summary from the last 12 months with remediation evidence. Vendors that need weeks to produce these don't have operational compliance programs — they have documents they update on demand.

What is DORA and does it apply to my dedicated team engagement?

The Digital Operational Resilience Act became enforceable in January 2025 for EU financial services entities and their ICT third-party service providers. If your dedicated team is working on systems for EU banks, insurers, investment firms, or other regulated financial entities, DORA applies. It adds contract-level requirements covering ICT risk management frameworks, incident reporting windows aligned with your regulatory obligations, and documented exit strategies with data portability provisions.