GDPR. A law that already applies to us, and a compliance program that does not exist yet

GDPR is not something a company obtains. It is binding law that already applies to us, and the documentation a serious buyer would ask for does not exist yet.

Nothing here is legal advice. If you are assessing your own position, ask counsel. We are not qualified to answer that and will not try.

Why this page is not shaped like the certification pages

Every other compliance item on this list is something a company obtains: an audit, a certification, a registration. GDPR is not. It is binding law with extraterritorial reach, and it applies to Solidus already, from the moment our pipeline processes an EU resident's personal data, by operation of law, whether or not we have a program around it.

So the honest framing is not "not yet." It is "it applies now, and our documentation does not match that."

And there is a second precision worth making, because vendors blur it constantly: there is no GDPR certificate to hold. The regulation does not issue one. Any company describing itself as "GDPR certified" is describing something that does not exist. What a serious buyer actually wants is the underlying documentation and independent verification, which is exactly what we do not have.

What it requires, in short

• A lawful basis for every use of personal data (Article 6). "We wanted it" is not one.
• Data minimisation and storage limitation (Article 5), collect only what the stated purpose needs, keep it no longer than that purpose requires.
• Individual rights, access, rectification, erasure (Article 17), portability, objection.
• Special-category data (Article 9), biometric data used to uniquely identify a person sits in a protected class with a higher bar for lawful basis and documentation than ordinary personal data. A face match for liveness is squarely in it.
• Privacy by design, and a Data Protection Impact Assessment for high-risk processing (Articles 25 and 35). Large-scale biometric processing is the textbook example regulators give, and the assessment is required before processing starts, not after.
• Enforcement with real penalties, applied by national Data Protection Authorities.

What we process, stated plainly

Government identity documents and biometric liveness captures, which is the category the regulation treats most seriously, and some of it belongs to people located in the EU.

We are not going to soften that by describing it as "verification data."

What exists in our code

Two things are real and checkable in the schema, and we would rather name them precisely than let them stand in for a compliance program:

• Retention windows are in the database, not in a policy document. Uploaded documents, identity images, selfies, voice audio, carry a purge timestamp defaulting to 30 days from capture. Session recordings carry one defaulting to 365 days, the window KYC audit expectations typically assume.
• A purge sweep enforces them. It deletes the stored object first and the database row second, so an interrupted run leaves a row that will be retried, never an orphaned file nothing points at. For identity documents the deletion is outright: object and row both go.

And the safety property, which cuts both ways: the sweep ships defaulting to dry-run. Until it is deliberately switched on it logs what it would delete and deletes nothing. That is a sensible default for code that permanently destroys personal data, and it also means a deployment that never flips the switch retains everything indefinitely while appearing to have retention. We flag it here because the failure is silent.

What does not exist

No published Data Protection Impact Assessment. No named EU representative or Data Protection Officer. No public Records of Processing Activities. No independent audit of any of the above. The Article 9 bar for biometric processing has not been publicly demonstrated as met.

Our own privacy pages are a statement of intent, not evidence. A company's word about its own practices is not proof, and we are not going to present it as such.

A retention window in a schema is a mechanism. GDPR compliance is a documented, assessed program. We have some of the first and none of the second.

The controller question we will not answer for you

Whether Solidus is a controller or a processor for a given deployment, and therefore who owes which obligations to whom, has real consequences and depends on the arrangement. That is a question for your counsel and ours, not one to settle on a product page. Any vendor that answers it for you in marketing copy is telling you something they cannot know.

Where reuse genuinely helps, and where it stops

Fewer copies is a real data-minimisation argument. A person verified once, presenting a credential afterwards, produces fewer sets of document images sitting in fewer vendors' storage than the same person verified separately at every relying party. That is the ecosystem-level version of Article 5, and it is the honest part of our case.

It does not discharge your obligation. You remain accountable for your own processing, your own lawful basis, and your own records, and whether accepting a third-party credential satisfies a given regulatory duty is unsettled. Reuse reduces copies. It does not transfer accountability.