1. Isolation
Every customer gets their own application instance and their own database. Your records are not rows in a shared table separated by a tenant identifier, which is how most software of this kind is built.
That difference is practical, not architectural vanity:
- a query written wrongly in one workspace cannot return another customer's data;
- a heavy report run by one customer does not slow another down;
- your data can be exported, moved or deleted on its own;
- an upgrade can be rolled out to one customer first, and a problem found there does not reach everyone else.
2. Credentials
- Passwords are stored only as salted bcrypt hashes. We cannot read them, and neither can anyone who obtains the database. A forgotten password is reset, never recovered.
- Password reset links are single-use, expire quickly, and invalidate every existing session for that account when used.
- Sessions are short-lived signed tokens, extended while you are working and expired on a fixed schedule regardless — a tab left open on a laptop does not stay signed in indefinitely.
- Changing a password invalidates every token issued before the change.
3. Who can reach your data
Within your company: access is granted by permission key rather than by a broad role, so a person can be given exactly what their job needs. A clerk who raises invoices does not thereby gain sight of the balance sheet. Your administrator controls this and can change it at any time.
Within ours: access to production infrastructure requires multi-factor authentication and is restricted to a private network. Our staff access a customer's data only where it is necessary to operate or support the service — investigating a fault you have reported, for example — and that access is recorded.
The administrative system that provisions and manages customer instances is not reachable from the public internet at all. The public website can ask it to create a workspace after a confirmed payment, and it can do nothing else — it cannot delete a customer, read another customer's data, or run arbitrary commands.
4. In transit and at rest
- All traffic to the website and to every workspace is encrypted with TLS.
- Secrets — database passwords, integration tokens, signing keys — are encrypted at rest and are never written into logs or error messages.
- Machine-to-machine calls between our own services are individually authenticated with short-lived signed tokens rather than a shared password.
5. Integration tokens
Authorisations for Google Drive, Dropbox, your bank connection and the platform you migrate from are held in a separate, dedicated service, not inside your workspace. Your workspace asks that service to act on your behalf and never holds the token itself, so a compromise of one instance does not expose a connected account.
Revoking a connection — from within your workspace, or from the other provider's own account settings — deletes the stored authorisation. Attachments held in your own Drive or Dropbox stay exactly where they are; we never held a copy.
Bank connections are read-only. They can see transactions and balances and cannot move money, and we never hold your online banking password — the connection is authorised at your bank, and revoking it there stops us immediately.
6. Payments
Card details never touch our systems. Payment is taken on the payment provider's own pages and infrastructure. We receive a confirmation and a reference, nothing more. There is no card data in our database to lose.
Payment confirmations arriving from the provider are cryptographically verified before they are acted on, and every one is recorded, so a repeated or forged notification cannot cause a second charge or a workspace nobody ordered.
7. Backups and recovery
- Databases are backed up on a regular schedule, and the backups are encrypted.
- Restores are tested, because a backup nobody has restored is a hope rather than a backup.
- After a subscription ends, a backup is retained for a limited period so an accidental cancellation can be reversed, and then deleted. The periods are in the Privacy Policy.
- Backups exist so we can recover the service. They are not a substitute for an export you hold yourself, and you can request one at any time.
8. Logging and audit
Sign-ins, permission changes and administrative actions are recorded. Application logs capture what is needed to diagnose a fault and deliberately exclude credentials, tokens and card data.
9. Export and deletion
Ask, and we will export your data in a form you can use elsewhere. Ask us to delete it and we will, subject only to records we are legally required to keep — invoices, for tax. We would rather be kept because the software is good than because leaving is difficult.
10. Reporting a vulnerability
If you believe you have found a security problem in our software or infrastructure, please tell us at contact@impactcodes.com with enough detail to reproduce it.
- We will acknowledge your report within two business days.
- We will tell you what we found and when it is fixed.
- We will not pursue you for a report made in good faith that stops at demonstrating the issue — please do not access other people's data, degrade the service, or run automated scans against production while investigating.
We do not currently run a paid bug bounty, and we will say so plainly rather than leaving you to guess.