Security

1. The short version

Register Quick LLC is a service of Quick LLC, 30 N Gould St Ste R, Sheridan, WY 82801, USA. We hold your company details, your owners, your documents and your deadlines, so we take a narrow, boring approach: few systems, data in one place we control, and access checked on the server every time.

Everything below describes how the software and the server are set up today. It is a description, not a certification.

2. Accounts and passwords

• Passwords are hashed with scrypt, each with its own random salt, and never stored in plain text. We cannot read your password or tell you what it is. Checks run in constant time, so a wrong password gives nothing away.
• Passwords must be at least 10 characters. Length is what makes a password hard to guess, so we ask for that instead of forcing symbol patterns.
• Links that set or reset a password are one-time and expire. Only a hash of the link is stored, so a copy of our database cannot be turned back into a working link. Issuing a new link retires the old one.
• Setting a password signs out other devices. Using a reset link ends every existing session for that account, and changing your password from inside the app ends every session except the one you are using.

3. Sessions

• Signing in sets one cookie, rq_session. It is httpOnly (scripts on the page cannot read it), SameSite=Lax (other sites cannot use it to act as you) and marked Secure in production, so it travels only over HTTPS.
• We store that token only as a hash, with the IP address and browser that created the session, so an unfamiliar session can be recognised.
• Sessions expire after 30 days. Logging out deletes the session on the server, not just in your browser — a copied cookie stops working at that moment.

4. Requests to our systems

• Same-origin checks. Any request that changes something and relies on your session cookie is refused unless it comes from our own site, which blocks the classic trick of making your browser act on another site's behalf.
• Rate limits per IP address. Sign-in, sign-up, the contact forms and the assistant each allow only a small number of attempts per network in a short window, which stops password guessing and automated abuse. We don't publish the exact thresholds, because that would only help the people we are limiting.
• Schema validation. Data sent to our API is checked field by field — types, lengths, allowed values — before anything is written. Incoming webhooks from Stripe and from our filing partner carry no browser session at all, and are refused unless their signature checks out.
• Roles are enforced on the server. Founder, partner firm and admin accounts see different things, and that decision is made on the server for every page and API call. The redirect that sends signed-out visitors to the login page is a convenience, not the protection: hiding a button in a browser protects nothing.
• Response headers. We send nosniff, a strict referrer policy, a permissions policy that switches off camera, microphone and location, and a content security policy that stops other sites framing ours. Your dashboard, checkout and login pages cannot be framed at all.

5. Transport and infrastructure

• The site is served over HTTPS. Cloudflare sits in front of it, providing DNS, TLS and content delivery.
• Everything runs on a dedicated server we rent from Hetzner Online GmbH in Falkenstein, Germany, and the database and your documents live on that machine. It is not shared public hosting.
• The application listens only on localhost, behind an nginx reverse proxy, and runs as an unprivileged user rather than as root. Nothing on the internet reaches it directly.
• Administrative access to the server is over SSH using keys, and the file holding our secrets is readable only by the account the application runs as.

6. Payments

Card payments are handled by Stripe on Stripe's own pages. Card numbers go to Stripe directly and never touch our systems, so there is nothing for us to lose. We keep only a payment reference, the amount and the status, and Stripe's notifications back to us are refused unless their signature checks out.

7. Confidential internal data

Our wholesale cost prices and partner agreement terms are restricted to admin accounts. The price list the public site uses is filtered on the server, so confidential values are never sent to a browser, even hidden in a page.

8. What we do not have yet — please read this one

Most security pages stop before this section. You are entitled to decide what to store with us on the full picture.

• No certifications. We do not hold SOC 2, ISO 27001 or any other security certification, and we have not had an independent audit or penetration test.
• No encryption at rest beyond what the host provides. The database and documents sit on the server's own disk; we add no application-level encryption on top.
• No automated off-site backups yet. This is the gap we are least comfortable with and the one we are working on first. Until it is closed, keep your own copy of any document that matters to you; you can download everything from your dashboard.
• No bug bounty programme. We do not pay for reported vulnerabilities. See the next section for what we do instead.
• No 24/7 security team. We are a small team in one time zone; reports and alerts are picked up during our working day, not within minutes at three in the morning.

So do not assume we have been audited, do not treat us as certified for a compliance requirement of your own, and do not rely on us as the only copy of anything you cannot afford to lose. As these change — and we intend them to — we will update this page and the date on it.

9. Reporting a vulnerability

If you find a problem, email [email protected] with “Security” in the subject line. Include what you found, the page or endpoint involved, how to reproduce it, and what you were able to access. We will acknowledge your report within 5 business days and tell you what we plan to do.

What we ask of researchers:

• Do not access, change or download other people's data. If a bug exposes someone else's record, stop at the point that proves it and tell us.
• Do not run denial-of-service, load or spam tests. Those affect real customers and prove nothing.
• Give us a reasonable chance to fix the issue before you publish it.

We do not pay bounties. If you would like credit, we will name you on this page and say what you found; if you would rather stay anonymous, that is fine too.

10. What we ask of you

• Use a strong password you have not used anywhere else — a password manager makes this painless.
• Keep the email address on your account secure. Anyone who controls that inbox can request a password reset, which makes it the real key to your account.
• If you are a firm, tell us as soon as a member of staff leaves so we can close their login. Access that outlives a job is an easy way in.
• Tell us immediately about anything you do not recognise — a filing you did not order, a document you have not seen, a sign-in you did not make.

11. If something goes wrong

If personal data is breached, we will notify the customers affected and, where the law requires it, the relevant regulators. We aim to do that without undue delay, and within 72 hours of becoming aware of the breach where the GDPR applies. We will tell you what happened, what data was involved, what we have done and what we recommend you do.

What we collect and why is in our privacy policy, the companies that process data for us are on our sub-processors page, and partner firms will find the contractual version in our data processing agreement. Anything else, email [email protected].