How should organisations collect real-time data in a compliant way during a public health crisis?

Collecting Health Data in a Crisis Without Breaking Privacy or Trust

Real-time collection during a public health crisis sits at the intersection of urgency, lawful processing, and public trust. Organisations may need to support triage, occupancy planning, exposure management, or service continuity, but the same data flows can quickly become disproportionate if purpose limits are weak or access is too broad. NIST Cybersecurity Framework 2.0 helps anchor this work in governance, protection, detection, and resilience, especially where collection pipelines become business-critical.

Compliant collection is not just about having a notice or a form. The real test is whether the organisation can justify why each data element is needed, who can see it, how long it is kept, and whether secondary use is blocked unless it has been approved. When crisis workflows are built quickly, teams often over-collect first and try to justify later, which is where avoidable exposure begins. In practice, many organisations discover the compliance gap only after emergency workflows have already widened data access beyond the original public health purpose.

How Compliant Real-Time Collection Should Work

A compliant crisis collection process starts with purpose limitation. The organisation should define the specific decision the data will support, then collect only the fields needed for that decision. If temperature, symptoms, location, attendance, or contact tracing data are requested, each one should have a documented reason tied to the public health objective rather than a general desire to be thorough.

Legal basis matters just as much as technical design. Depending on jurisdiction and context, consent may be appropriate, but it is not the only possible basis. Some crisis scenarios rely on public interest, legal obligation, employment policy, or public health powers. The key is that the chosen basis must match the context and be recorded before collection expands. Where consent is used, it should be meaningful and not bundled into broader access to services unless the law allows that approach.

Security controls should be built into the workflow, not added after deployment. That means access restriction by role, logging of collection and sharing events, controlled export of datasets, and retention settings that remove data when the emergency use case ends. Organisations should also align the collection pipeline with privacy review and incident response so that misuse, over-retention, or unauthorised disclosure can be detected and contained quickly. If the same data feeds dashboards, alerts, and external reporting, each destination should be approved separately rather than treated as an automatic extension of the original request.

• Define the exact public health decision the data supports.
• Map each data field to a lawful basis and a retention rule.
• Restrict access to the smallest operational group that needs the data.
• Log sharing, export, and deletion actions for auditability.
• Review whether collection still remains necessary as the crisis changes.

For broader crisis governance, the most useful external control perspective is NIST Cybersecurity Framework 2.0, because it connects governance and operational resilience to data handling in a way that suits rapidly changing environments. The guidance breaks down when organisations cannot keep the purpose statement, access model, and retention practice aligned as the response evolves.

When Emergency Conditions Change the Answer

Tighter real-time collection often increases operational friction, so organisations have to balance speed against minimisation and accountability. That trade-off becomes sharper when the crisis is evolving and the data model is still changing. In some situations, public health law or sector-specific regulation may justify broader collection than would be acceptable in normal operations, but that does not remove the obligation to document why the exception exists and when it stops.

One common edge case is secondary use. Data collected for workplace safety, for example, may not be automatically available for disciplinary, insurance, or marketing purposes. Another is aggregation: even when individual-level collection is limited, combining datasets can create a richer profile than the original purpose required. Organisations should also be careful where third parties process the information, because processor access does not make the use compliant by default. If a vendor, platform, or integration partner cannot support the same purpose, access, and retention constraints, the arrangement needs to be redesigned or excluded.

There is also a practical consensus issue: some jurisdictions and regulators give stronger weight to public health necessity during emergencies, while others still expect strict minimisation and transparency. The safer operating assumption is to treat emergency powers as a temporary justification, not a blanket exemption. Where the collection model begins to outlive the crisis decision it was meant to support, compliance risk turns into governance failure.

Practitioner Guidance

What to prioritise: Start with the decision the data must enable, then remove every field that does not materially change that decision. If a collection item cannot be tied to a current operational use, it should be treated as optional at best and excluded at worst.

What to verify: Confirm that the lawful basis, notice language, retention period, and access model all describe the same real workflow. A frequent mistake is approving the privacy statement while the live data route, export path, or dashboard permissions quietly expand beyond it.

Decision rule: If the crisis use case has changed, review the collection design immediately rather than waiting for the formal programme review cycle. Temporary necessity should narrow over time, not harden into a standing surveillance pattern.

Practitioner takeaway: The most defensible crisis collection model is the one that can prove necessity at the field level, not just explain urgency at the programme level.

Related resources from NHI Mgmt Group

• How do organisations reduce the dwell time of exposed credentials at scale?
• Why do organisations need real-time remediation instead of discovery alone for sensitive data risks?
• What breaks when organisations rely on monitoring alone instead of real-time enforcement for Salesforce data security?
• When should organisations prioritise real-time bank data over document-based verification?