A customer forming a company hands over a passport scan, a proof of address and a set of corporate documents. That package is more sensitive than most of what a typical application stores, and this page describes how it is handled.
Everything below describes a control that exists today. Anything planned rather than implemented is on the technology page, labelled as planned.
Traffic to this site and to the group applications is served over HTTPS, and stored documents are encrypted at rest. Encryption at rest protects against physical loss of a disk; it is not a substitute for the access controls below, and this page does not present it as one.
Access is granted for a defined purpose and scope rather than as a permanent property of an account. Elevated access is temporary by default, so nobody has to remember to take it away.
Fields that are not needed are not collected. The contact form asks for what is required to answer the enquiry and nothing more, and the site sets no analytics, advertising or tracking cookie.
Corporate documents are treated as the security boundary rather than the login. A document is authorised at the moment it is read, links to documents are short-lived rather than permanent, and downloading is a separate permission from viewing.
Retention is defined per document type, based on why it was collected and what record-keeping obligation applies. Deletion is a scheduled process rather than a clear-out somebody remembers to run: a document you no longer hold cannot be exposed.
Database access goes through prepared statements without exception, output is escaped at the point of rendering, and every state-changing form carries a CSRF token. Credentials are kept out of the tracked configuration file.
Application errors are logged server-side and never shown to a visitor in production. Logs are written to be useful for diagnosis without carrying more personal data than the diagnosis needs.
Backups are taken on a schedule and encrypted. The measure that counts is not whether a backup exists but whether a restore has been performed and timed by someone other than the person who set it up.
The scenario planned for is the ordinary one: a bad deployment corrupts data, or something is deleted in the wrong environment. Written down are how it is noticed, who decides to restore, how much data is lost and what customers are told.
Providers are engaged by category — hosting and mail, registries, identity verification, payment processing — and each is limited to the data its function requires. Card details are never stored by Dorsko.
Where an automated result would affect someone's company, money or identity, a person reviews it before it is acted on. Confidence indicators route work to a reviewer; they do not remove one.
A researcher who finds a problem has a published address to send it to and a stated response time. That is the whole programme — there is no bounty, and this page does not imply one.
A security page that claims everything says nothing. These are the assurances Dorsko does not have, stated plainly so nobody has to infer them from silence.
If any of these changes, it will appear here with the certificate, the auditor and the date — not as a badge on a marketing page.
If you have found a problem in this website or in any Dorsko product, please tell us before telling anyone else.
We will acknowledge your report within five working days and tell you what we intend to do about it. We will not take legal action against anyone who follows the guidance above.
security.txt · The same address is published in machine-readable form under RFC 9116.
Listed by category rather than by brand. Naming a vendor publicly is a statement about a contract, and a category is the honest level of detail until each agreement has been checked for what it permits.
| Category | Purpose | Location |
|---|---|---|
| Web hosting and email delivery | Serving this website and the group applications, and delivering transactional mail. | European Union / United Kingdom |
| Company formation registries | Submitting incorporation filings on behalf of customers of the formation platforms. | Jurisdiction of the filing |
| Identity verification providers | Checking identity documents where a filing or an onboarding step requires it. | European Union / United Kingdom |
| Payment processing | Taking payment for services on the live platforms. Dorsko does not store card details. | European Union / United Kingdom |
| Status page and uptime monitoring | Publishing service availability, and the badge embedded in the footer of this site. | European Union / United States |
Each provider receives only the data its function requires. Where a provider is added or changed, this table is updated before the change goes live.
