Case File 1

Vendor-Scale Identity and Metadata Failure

Data Continuity and Sovereignty Test

Microsoft — An Article 15 (UK GDPR) Case Study

Executive Summary

This case study documents a practical, evidence-based test of data continuity and data sovereignty using a lawful UK GDPR Article 15 Subject Access Request (SAR). The test was designed to determine whether a major cloud vendor can guarantee the unbroken existence of a person's digital identity—understood not merely as stored files, but as the metadata that constitutes identity, history, relationships, and meaning.

The outcome demonstrates a structural gap: while data containers persist, continuity does not. Essential metadata remained fragmented, non-guaranteed, and—at times—unreachable through prescribed routes. The case therefore defines, in practice, what data sovereignty is and is not in contemporary cloud systems.

1. Purpose of the Test

The objective was not to recover individual files. The objective was to test whether continuity—defined as unbroken existence over time—is actually offered by vendors who control identity and metadata.

Research questions:

  • Does the vendor guarantee preservation and disclosure of controller-side metadata that defines existence?
  • Can a data subject reconstruct identity continuity independently of the vendor?
  • Is "your data" sovereign if metadata authority is retained by the controller?

2. Definition Framework

2.1 Linguistic Baseline (Oxford Languages)

Continuity is defined as "the unbroken and consistent existence or operation of something over time."

2.2 Operational Extension (This Study)

Operational Continuity: The ability of an identity or record to preserve its meaning, structure, and authority over time despite changes in platform, policy, access, or vendor control, and to be reconstructed without reliance on any single external provider.

Data Sovereignty: The condition in which the subject retains authority over the metadata that constitutes identity, relationships, and meaning, independent of vendor leverage.

3. Methodology

3.1 Instrument

A formal UK GDPR Article 15 SAR requesting all controller-side personal data, including:

  • Identity and account history
  • Support and CRM records
  • Audit logs
  • Call recordings announced by the controller
  • AI interaction history

3.2 Rationale

Article 15 was selected because it is the only statutory mechanism that compels disclosure of controller-side metadata—not just user-visible content.

3.3 Evidence Handling

All correspondence, timelines, and disclosures were archived contemporaneously and indexed for audit.

4. Case Background

Over multiple decades, a single email address existed across evolving Microsoft identity systems (standalone products → MSA → Microsoft 365 → Entra ID). As licensing and identity models changed, identity fractured into parallel realms.

Observed effects:

  • Inconsistent authentication
  • Disappearing historical support records
  • Inaccessible files encrypted to obsolete identities
  • Loss of Copilot and AI interaction history

No supported mechanism existed to merge or preserve identity history without loss.

5. Timeline (Condensed)

  • 27 Nov 2025: Article 15 SAR served
  • Dec 2025: SAR deflected into support channels; privacy portal link returned 404
  • 27 Dec 2025: Statutory deadline elapsed without fulfilment
  • Jan 2026: Evidence bundle prepared; escalation to ICO
  • Apr 2026: Partial success in separate AI-interaction SAR; main continuity SAR unresolved

6. Findings

6.1 Containers vs Continuity

The vendor was able to state—accurately under its model—that data may exist, while simultaneously disclaiming responsibility for reconstructing identity continuity.

Key finding: When metadata breaks, existence breaks—even if files persist.

6.2 Absence of Metadata Guarantees

No contractual guarantee exists for:

  • Identity history preservation
  • Metadata continuity across account transitions
  • Reconstructability after identity fragmentation

6.3 Delegated Existence

Existence was shown to be conditional on vendor-held metadata. Conditional existence is not continuity.

7. Regulatory Outcome

The ICO's initial decision did not escalate enforcement, citing thresholds of harm and public interest. Importantly, the decision did not:

  • Assert compliance with Article 15
  • Deny that metadata is personal data
  • Resolve the continuity loss

The SAR remained substantively unfulfilled.

8. Interpretation

This case demonstrates that major vendors currently provide containers, not continuity.

  • Storage ≠ existence
  • Availability ≠ sovereignty
  • Backups ≠ continuity

If a third party controls the metadata that defines you, your existence is delegated—and delegation breaks continuity.

9. Implications

9.1 For Individuals

  • Cloud lock-out can equal identity loss
  • "Your data" may be unusable without vendor recognition

9.2 For Regulators

  • Continuity harm is structural, not emotional
  • Metadata deserves explicit regulatory treatment

9.3 For System Design

  • Local authority over metadata is mandatory
  • Cloud must be replica, not arbiter

10. Design Response

This case directly informed the development of a local-first continuity architecture:

  • Metadata held locally
  • Identity anchored outside vendors
  • Cloud used for replication only
  • Full reconstructability without permission

See the ContinuityID architecture for how this addresses the failure modes above.

11. Conclusion

The Article 15 test succeeded in its purpose.

It established, on the record, that data sovereignty does not exist where metadata authority is retained by vendors without guarantee. Continuity, as defined by unbroken existence, cannot be rented.

If a vendor holds the metadata, your existence is broken.

Appendices

Appendix A — Evidence Index

  • ICO Submission Packs (multiple iterations)
  • Correspondence logs
  • Privacy portal error capture
  • Partial AI-interaction disclosure

Appendix B — Reproducibility

This test can be reproduced against any cloud provider using the same Article 15 methodology.