The delegation pattern
A common response to the ISO 31030 / GDPR Article 9 conflict is not to avoid collecting sensitive data, but to avoid collecting it directly. The enterprise contracts a specialist assistance or medical-support vendor. The employee discloses health conditions, medication needs, or other special-category information to that vendor under a duty of confidentiality. The vendor evaluates the traveller and returns an operational instruction to the enterprise, cleared to travel, not cleared, restrictions apply, without passing along the underlying medical detail.
This is a real and widely used pattern, and it solves a real part of the problem: the enterprise itself never holds the sensitive attribute.
What delegation actually resolves
The enterprise's own liability under Article 9 is genuinely reduced. If the enterprise never receives or stores the special-category data, it cannot be the party that mishandles it, and a regulator examining the enterprise's own systems will not find a special-category dataset to examine. This is not a cosmetic distinction; direct possession is what Article 9 primarily governs, and removing it from the enterprise's own systems removes the enterprise's own direct exposure.
What delegation relocates rather than resolves
Three things do not change under the delegation pattern.
The data still exists centrally, one hop away. The sensitive attribute is no longer held by the enterprise, but it is still collected, processed, and typically retained by the vendor, usually across that vendor's entire client base. The special-category dataset has not been eliminated. It has been consolidated into a single third party who serves many enterprises at once, which can make that vendor a higher-value target than any single enterprise's HR system would have been on its own.
The guarantee is contractual, not architectural. What protects the enterprise and the traveller under this model is a confidentiality clause, a data processing agreement, a medical-secrecy obligation. Those are real and legally enforceable, but they depend on the vendor's ongoing discipline, security posture, and good faith. An architecture that never collects the data in the first place does not depend on any party choosing not to misuse data it holds, because no party holds it. A contractual guarantee and a structural impossibility are different kinds of protection, and it is worth being precise about which one a given arrangement actually offers.
The traveller has less visibility into, and less control over, who now holds their information. Under delegation, the employee is generally required to disclose to whichever vendor the enterprise has selected, a third party the employee did not choose and may not have an ongoing relationship with beyond this transaction. The data resides with an organisation whose retention policies, breach history, and downstream data-sharing practices the traveller cannot see and did not negotiate.
Where delegation is still the right tool
Delegation is not a workaround to be replaced in every case. Genuine medical emergencies, evacuation coordination, and situations requiring a licensed clinical judgement are properly the domain of a medical or assistance provider, not an on-device assessment. The distinction that matters is between ongoing operational risk assessment (is this traveller, with these circumstances, ready for this specific trip) and acute medical response (this traveller needs care right now). Delegation is well suited to the second. It is a partial answer to the first, because the first does not require a third party to hold the underlying attribute at all, only to evaluate it once and discard it.
The architectural alternative
Delegation asks who should be trusted with the traveller's sensitive profile. Minimum-disclosure architecture asks a different question: why does anyone beyond the traveller need to receive the profile at all.
Minimum-disclosure architecture addresses the first case, ongoing pre-travel readiness assessment, differently: the evaluation happens on the traveller's own device, against that specific trip, and the underlying attribute is never transmitted anywhere, not to the enterprise and not to a third-party vendor. What leaves the device is a state (Ready, Needs Review, Not Ready) and a sanitised receipt that the assessment occurred. There is no third party to select, no consolidated dataset to become a target, and no contractual promise standing in for a structural one. See The Minimum-Disclosure Data Boundary for the full mechanism.