Privacy
Last updated 11 August 2026
This service stores vulnerability and incident records, some of which describe flaws that have not yet been fixed or reported. That shapes everything below: what is collected, how long it is kept, and the one place where deletion is genuinely constrained.
Controller. Linclaw Consulting AB, publishing under the Skarp name.
Org. nr 559074-9239
Prästkvarn Gamla Skolan 1
542 94 Mariestad
Sweden
Contact cra@skarp.app. Everything a data processing agreement needs to identify us is on this page; ask if you need it in a signed document.
What is collected
Account data
An email address, and a display name if you supply one. Credentials are connector tokens: only a bcrypt hash of each token is stored, so a token cannot be recovered from the database — if you lose one, it is reissued rather than retrieved.
What you record about your products
Everything you enter through the tools: product descriptions and intended use, classification decisions and their reasoning, risk assessments, Annex I requirement status and justifications, evidence artifacts and their provenance, vulnerability and incident records including severity and exploitation status, reporting deadlines and submission references, and the names and roles of people who sign off on technical documentation.
Evidence is stored by value — the artifact itself, not a link to it — because a reference proves nothing years later. Do not paste credentials, customer personal data, or anything you would not want retained for a decade into evidence bodies.
Activity
Every change to a product's compliance record writes an audit entry: what changed, when, which agent or model performed it, and which account is accountable. This trail is the product. It is what evidences that your technical documentation was maintained, so it is append-only and is not edited to look tidier after the fact.
Visitor statistics
The public pages count visits using Plausible Analytics. It sets no cookies, stores no identifier on your device, and does not follow you to any other site. There is no advertising, and nothing here is sold or shared for marketing.
Both the script and the events it sends are proxied through this domain, so your browser never connects to Plausible — which is why the footer can still say nothing loads from another host. What reaches Plausible from our server is the page you viewed, the referrer, your browser and device type, your country, and, so that repeat visits are not counted twice, your IP address. Plausible derives a hash from it with a salt that rotates every 24 hours and does not store the address; once the salt rotates, a visit cannot be linked to an earlier one. Plausible Insights OÜ is an Estonian company and hosts this in the EU.
Also recorded: that a form was submitted, that an outbound link was clicked, and that a file was downloaded. Never what you typed into a field — not the email address on the sign-in form, not anything else.
The signed-in console is excluded entirely. No page under
/app carries this, because those URLs contain product identifiers
and those have no business leaving this host. The policy header served with
those pages permits no script to run at all, so it is enforced rather than
merely intended.
All of that is about this site in your browser. The service itself makes one outbound request on your behalf — see where it is processed.
Why, and on what basis
- To provide the service — performance of a contract. Your compliance records exist because you asked the tool to keep them.
- To keep it secure — legitimate interests: rate limiting, bcrypt-hashed credentials, per-product access checks and the audit trail.
- To count visits to the public pages — legitimate interests: knowing which pages get read, with no cookie, no device identifier and no profile built about anyone. Nothing is stored on your device, so there is nothing to consent to; any tracker blocker stops it.
- To warn you about deadlines — performance of a contract. Email alerts go to the members of a product as its statutory deadlines approach. This is on by default, because a compliance tool that silently stops chasing a legal deadline has failed at its job.
Where it is processed
Hosted on Amazon Web Services in eu-north-1 (Stockholm). Database, backups and outbound email all stay in that region. AWS provides compute and storage, plus Amazon SES for notifications. No analytics or error-tracking service receives your data.
Payments go through Stripe, and only if you buy something. Stripe receives your email address and whatever you type into their checkout; it is their form, on their systems, and card details never reach this service — we could not store them if we wanted to. What comes back to us is an identifier for your subscription and which plan you are on. Nothing about your products, vulnerabilities or technical documentation is ever sent to Stripe.
Plausible receives the visitor statistics described above from the public pages, in the EU. Nothing about your account, your products or your vulnerability records is ever sent to it, and the console does not carry it at all.
That is the complete list of people who touch your data: AWS, Stripe if you pay, Plausible for visits to the public pages, and the advisory sources named below.
One thing does leave, and only one
To warn you about vulnerabilities in components you ship, the service checks your software bill of materials against three public sources: the OSV advisory database, CISA's Known Exploited Vulnerabilities catalogue, and EPSS, which estimates how likely each CVE is to be exploited.
Only the first of those sends anything. KEV and EPSS are
downloaded whole and matched on this host, so nothing about your product is
disclosed for either — that is why they are mirrored rather than queried
per-CVE, since asking a scoring API about the CVEs affecting your components
would reveal exactly what the mirror avoids. Querying OSV does send data: the
package name, ecosystem and version of each component — for
example requests, PyPI, 2.31.0. Never
the SBOM document itself, which also carries supplier names, file paths and
hashes; never your product name, your account, or anything you have recorded
about vulnerabilities or incidents.
A dependency list can still be commercially sensitive. An operator can turn
the check off entirely with CRA_ADVISORY_SCAN_ENABLED=0, in which
case nothing leaves this host at all — and you get no proactive warnings.
How long it is kept — and the honest caveat
The CRA puts this duty on the manufacturer — on you — and not on this service. Article 13(13) requires you to keep the technical documentation and the EU declaration of conformity at the disposal of market surveillance authorities for at least ten years after the product is placed on the market, or for the support period, whichever is longer. Article 13(18) sets the same period for the Annex II information that accompanies the product. Nothing in the regulation obliges us to keep anything, and our holding a copy does not discharge your obligation.
We hold that copy so the record is there when you need it, and retention here is longer than most services because of it. Being exact about what that means today: everything you record is kept for as long as your account exists — not only the documents those articles name, but the audit trail, vulnerability and incident records, advisory scans and working drafts. That is broader than the regulation requires. Narrowing it to the classes that genuinely need decade-scale retention is planned work, not something already in place, and this page will say so plainly when that changes.
Two kinds of copy, kept for different lengths of time. Nightly database backups exist for disaster recovery. Since 9 August 2026 they are written to Amazon S3 without Object Lock and expire automatically after 90 days, so an erasure request reaches them by waiting.
A small number of full-database snapshots taken before that change — six, dated 5 to 9 August 2026 — are still held under Object Lock and cannot be removed by ordinary means until August 2036. We would rather say so than round it off: they are the reason the paragraph below exists.
Separately, the statutory record — a frozen technical file, a declaration of conformity, a simplified declaration, a sign-off, and the release each is tied to — is copied into a locked archive under Object Lock in governance mode, with a retention period set per object and never shorter than the ten years Article 13(13) requires. The copy is scheduled when the record is created and uploaded on a daily pass, so it can be up to a day behind. Those objects cannot be deleted by ordinary means before their period expires. This is the record the regulation obliges a manufacturer to keep available, and keeping it is the point of the service.
Governance mode means a specifically privileged administrator can remove an object before expiry, so an erasure request is not impossible — but it is a deliberate, logged, manual operation rather than something the application can do.
Erasure today is manual, and we would rather say so. The application has no self-service delete: asking us to remove your data starts a hand-run operation against the live database, not an automated one. We will confirm when it is done and tell you what remains in the locked archive and until when. An automatic lifecycle for data that is not part of the statutory record is planned and is not yet built.
Where a record is part of the evidentiary trail for a technical file — an audit row, a signed attestation — erasing it would destroy the very thing that demonstrates compliance. In those cases we will explain the conflict rather than quietly refuse.
Your rights
Under the GDPR you can request access to your personal data, correction of it, erasure, restriction of or objection to processing, and a portable copy. Write to cra@skarp.app. You also have the right to complain to your national data protection supervisory authority.
Most of what this service holds is information about products rather than people. The personal data is small: account emails, display names, the names and roles of signatories, and a security contact address if you record one.
Security
- TLS on every connection; the API is not reachable over plaintext.
- Connector tokens are bcrypt-hashed; the plaintext is shown once, at issue, and never stored.
- Every product-scoped operation checks membership — holding a product identifier grants nothing on its own.
- The service's own database runs under a dedicated role with the public connect grant revoked, so a credential compromise elsewhere on the host does not reach it.
To report a vulnerability in this service, write to cra@skarp.app. Given what the tool is for, we would rather hear about it early and awkwardly than late and politely.
Changes
Material changes will be reflected here with a new date at the top, and notified to account holders by email where the change affects how their data is handled.