Compliance

VCT Registry's compliance footprint is deliberately minimal. No personal data. Public resolver. Thin obligations.

GDPR

No personal data flows through VCT Registry — only credential-type schemas and display metadata. Operator identifiers (e.g. "published by Ministry of X") may appear in metadata; these are organisational, not personal. No Art. 30 processing obligations beyond standard service-operator hygiene.

ARF alignment

VCT Registry implements the SD-JWT VC type-metadata spec. Qualified ecosystems (member-state attestation registers, EUDIW display-metadata services) can reuse the same shape.

NIS2 — availability + integrity

Because verifiers resolve VCTs on potentially-hot paths, availability matters. VCT Registry supports horizontal scaling, long Cache-Control headers to keep load off the service, and standard health-check endpoints. Integrity: metadata JSON is served as-is, versioning is cryptographically irrelevant (nothing is signed), but any integrity breach is operationally obvious (different schema returned → different credential rendering → audit triggers).

Operational obligations

• Stable URLs — deprecation via metadata flags, not by removing the endpoint
• Audit trail for admin CRUD (on roadmap alongside Postgres persistence)
• Transparent deprecation policy — give wallets time to surface v2, let v1 continue to resolve