The HDS v2.1 transition isn't failing because your team doesn't understand the technical requirements. It's failing because you're treating contract updates as a documentation task instead of a cross-functional compliance project.
I've seen organizations smoothly transition through v2.0 only to stumble when v2.1's expanded contract disclosure requirements hit their legal and procurement workflows. The certification body finds gaps during the audit that could have been caught months earlier. The pattern repeats: technical teams build the controls, legal reviews the language in isolation, and nobody validates that the contract actually reflects what the infrastructure does.
Here's what's going wrong and how to fix it before your next audit.
Why These Mistakes Keep Happening
HDS v2.1 shifts compliance weight from Technological Controls to contractual transparency. Requirements 23-1, 23-2, and 23-3 don't ask you to change how you host data; they demand that you disclose it accurately in customer contracts. That disclosure must cover data transfer scenarios, remote access governance, third-country legislation impacts, adequacy decisions, mitigation measures, and residual risks.
Most teams aren't structured for this. Your information security team knows where data flows and who accesses it remotely. Your legal team knows contract language. Your compliance team knows the certification requirements. But these groups rarely work from a shared artifact that maps infrastructure reality to contractual obligations, and that gap creates every mistake below.
Mistake 1: Treating Article R.1111-9-1 as a Reference, Not a Requirement
Why it happens: Requirements 28 and 29 now reference Article R.1111-9-1 of the French Public Health Code. Teams see the citation, assume their legal counsel will handle it, and move on.
The consequence: Your contract template gets updated with boilerplate language about EEA data storage, but it doesn't actually describe your specific transfer scenarios. When the auditor samples contracts during surveillance, they're testing whether the language matches your actual data flows and remote access patterns. Generic references fail that test.
The fix: Map every remote access scenario and data transfer pathway in your infrastructure. Document which systems allow access from outside the EEA, which third-country regulations apply to any subcontractors, and whether an EU adequacy decision covers those countries. Then write contract language that describes these specifics, not just the principle. Requirement 29 is explicit: remote access from outside the EEA is a data transfer and must be disclosed with applicable safeguards under GDPR Article 46.
Mistake 2: Updating Template Contracts Without Amending Existing Agreements
Why it happens: Legal updates the master contract template to reflect v2.1 requirements, compliance checks the box, and everyone assumes the work is done. But your certification scope includes all active hosting agreements, not just new sales.
The consequence: During the audit, the certification body samples from your current customer base. Half your contracts were signed before v2.1 took effect and don't include the expanded disclosure requirements in 23-1, 23-2, or 23-3. That's a finding, and it delays your certificate issuance while you chase down contract amendments.
The fix: Build a contract amendment project alongside your template update. Identify every active hosting agreement in scope for HDS certification. Draft amendment language that incorporates Requirements 23-1 through 23-3 and the expanded patient rights disclosure under Requirement 19. Execute those amendments before your next audit cycle. This isn't optional; your CB will test a sample of live contracts, and they must reflect v2.1.
Mistake 3: Publishing the Requirement 31 Transparency Map Without Contract Alignment
Why it happens: Requirement 31 mandates a public map of all personal health data transfers outside the EEA, including remote access and risks of unauthorized access. Teams publish the map to meet the transparency obligation but don't cross-check it against what their contracts say.
The consequence: Requirement 23-3 explicitly states that the information published under Requirement 31 must be stated in the contract. If your public map lists three third-country subcontractors but your contract template only mentions two, you've created an audit gap. The CB will flag the inconsistency because it suggests either incomplete disclosure or inaccurate public representation.
The fix: Treat the Requirement 31 map and your contract disclosure requirements as a single control. Before you publish the map, validate that every transfer scenario, remote access pathway, and residual risk it describes is also enumerated in your contract templates and amendments. Update both artifacts together, and version-control them so you can demonstrate alignment during the audit.
Mistake 4: Assuming Activity 6 Renaming Is Just a Label Change
Why it happens: HDS v2.1 renames Activity 6 to explicitly cover electronic archiving services as part of the backup of health activity. Teams update their certificate scope statement and assume that's sufficient.
The consequence: If you offer electronic archiving, you're now unambiguously within scope for HDS certification under the SREN Act. But renaming the activity doesn't automatically bring your archiving processes into compliance with the full HDS framework. The CB will audit your archiving controls against all applicable requirements, including data sovereignty, access governance, and contractual disclosure. If your archiving service was previously treated as out-of-scope and you haven't implemented controls, you're not ready.
The fix: If you provide electronic archiving services, conduct a gap assessment against the HDS v2.1 requirements as if it were a new activity. Verify that archiving data stays within the EEA, that access controls meet the framework's standards, and that your contracts describe archiving-specific data flows. Update your certification scope intentionally, not just semantically.
Mistake 5: Delaying CB Engagement Until the Audit
Why it happens: Organizations wait until their scheduled surveillance or renewal audit to discuss v2.1 changes with their certification body. They assume the CB will interpret the new requirements during the audit and provide guidance then.
The consequence: By the time you're in the audit, it's too late to fix structural gaps. If your CB interprets Requirement 23-2's third-country legislation disclosure differently than you anticipated, you can't revise contracts mid-audit. You'll receive a nonconformity, your certificate issuance gets delayed, and you're scrambling to remediate under deadline pressure.
The fix: Engage your CB before your next audit cycle begins. Schedule a pre-audit consultation to review your updated contract templates, your Requirement 31 transparency map, and your interpretation of the new data transfer and remote access disclosure obligations. Ask how they'll sample contracts and what evidence they'll request. Certification bodies like Schellman are updating their audit programs to verify that new contract templates incorporate the revised requirements and that existing contracts have been updated; understanding their testing approach early lets you align your preparation work with their expectations.
Prevention Checklist
Before your next HDS v2.1 audit:
- Map all remote access scenarios and data transfer pathways involving third countries outside the EEA
- Update contract templates to include Requirements 23-1, 23-2, 23-3, and expanded patient rights under Requirement 19
- Execute amendments to all active hosting agreements to incorporate v2.1 disclosure requirements
- Cross-check your Requirement 31 public transparency map against contract language for alignment
- If you offer electronic archiving, conduct a gap assessment and implement controls for the renamed Activity 6
- Engage your certification body for a pre-audit review of updated contracts and documentation
- Document the governance process you used to align legal, technical, and compliance teams on contract updates
- Version-control your contract templates, amendments, and transparency map so you can demonstrate when changes took effect
The v2.1 transition isn't about building new infrastructure. It's about proving that your contracts accurately represent how you protect health data. Get your legal, technical, and compliance teams working from the same map, and you'll avoid the gaps that delay certifications.
