DPAregister
EN · NBSign in
How it works

Facts in, verdicts out

The register never asks how compliant you feel. It collects facts, derives verdicts, and leaves every conclusion that needs a human to a human.

1

The facts arrive

Your CI posts a manifest of what each repo depends on. The egress and CSP observers report which hosts production actually talks to. Your accounting ledger names the vendors you pay. Three angles on the same truth.

2

Verdicts are derived

Every contract × sub-processor pair gets a verdict from the facts: where it runs, what the paper allows, whether a transfer mechanism holds and is still dated fresh. Recomputed nightly, and on every change.

3

A person sends the notice

When a new sub-processor lands under a prior-notice agreement, the register writes the debt. A person reads it, presses send, and the customer gets one letter with everything they are owed. The window starts at the telling.

4

The customer answers on their page

Acknowledge, or object with the clause it conflicts with. An objection goes to a person on your side. Silence is recorded as silence.

Where the facts come from

CI manifests
A JSON post from your pipeline naming each repo's dependencies. The register maps them to vendors and asks a human to confirm what is real.
Egress & CSP observation
Hostnames only, reported by your running systems. A host nobody registered becomes a pending dependency, never a silent entry.
The accounting ledger
Tripletex, Fiken or a CSV reskontro. An unmatched supplier is potential shadow IT; an unmatched customer is a controller with no paper.
A person, always
Every fact that becomes a register entry passes a human ruling. The machine collects and derives. It never concludes.

See it against your own stack

Bring one product and one contract. The first verdicts take an afternoon.

Sign in