Fiskwise Security Overview
1. What this page is
1.1 This page describes the security measures actually built into Fiskwise, in plain language, and, just as deliberately, the attestations we do not hold (section 6). It supports section 12 of the Privacy Policy and sits alongside the Terms of Service, the Refund and Cancellation Policy and the Subprocessor List.
1.2 Every statement here describes the shipped software. Where a protection depends on our hosting provider rather than our code, we say so.
2. Isolation: your workspace cannot see another
2.1 Tenant isolation is enforced by the database, not by application code being careful. Every tenant-scoped table, roughly 300 of them, has PostgreSQL row-level security enabled and forced, with an isolation policy keyed on the workspace identifier. "Forced" matters: the policy applies even to the table's owner.
2.2 The application connects as a dedicated non-superuser role that cannot bypass row-level security, and the service refuses to start if it detects it has been pointed at a privileged connection instead. A query that omits the workspace scope returns nothing rather than someone else's rows.
3. Encryption
3.1 In transit. The service is served over HTTPS/TLS, and the application refuses to start unless its public origins are HTTPS. Responses carry Strict-Transport-Security, so a returning browser will not downgrade to cleartext.
3.2 At rest, field level. The highest-value secrets are individually encrypted with AES-256-GCM under separate, rotatable keys held outside the database: bank aggregator access tokens, supplier payment credentials, third-party integration tokens, currency-feed API keys, and supplier tax identification numbers (stored in a dedicated vault; the record itself carries only a masked display string). The service refuses to start if a key is missing or malformed, so it cannot silently fall back to a default key, and each ciphertext records its key version so keys can be rotated.
3.3 At rest, disk level. The database is a managed PostgreSQL instance at our hosting provider, and disk-level encryption at rest is a property of that provider's infrastructure rather than of our code: [TO OPS: confirm the hosting provider's disk-encryption posture and state it here before publication.]
3.4 Stored as hashes, never retrievable. Passwords, API keys, invitation tokens and export download tokens are stored only as cryptographic hashes. No endpoint returns them, and a copy of the database does not contain them.
4. Access control and accounts
- Role-based access control with granular permissions, so you decide what each user can see and do. Sensitive actions such as voiding a posted journal entry are restricted to the workspace Owner.
- Two-factor authentication: server-side support (authenticator app plus backup codes) is built; the in-app enrollment and sign-in challenge screens are under development and will ship before we recommend it broadly.
- Breached-password screening: at sign-up and password change, the candidate password is checked against known breach corpora using a k-anonymity range query, so the password itself never leaves the server. A breached password is rejected.
- Rate limiting on the authentication endpoints (sign-in, sign-up, password reset, verification email) slows credential stuffing and abuse.
- Session cookies are HttpOnly, Secure over HTTPS, and SameSite=Lax. Completing a password reset revokes every other session on the account. Cross-origin requests are restricted to an explicit allowlist and origin-checked.
5. The plumbing that faces the internet
- Inbound webhooks are cryptographically verified before anything is written: HMAC signature checks with a replay window for the payment processor, pinned JWT signature verification for bank feed events, and a constant-time shared-secret check for email delivery events. An unverified request changes nothing.
- Outbound webhooks you configure are guarded against server-side request forgery: the destination address is resolved and validated before any connection is made, so a webhook cannot be pointed at internal infrastructure.
- Security headers are set on responses: a Content-Security-Policy,
Strict-Transport-Security,X-Content-Type-Options: nosniff,Referrer-Policy, and frame-ancestor restrictions. - Uploads and exports are size-bounded, and error responses are redacted: an unexpected server error returns a generic message, never a stack trace or internal detail.
6. What we do not have, stated plainly
6.1 We hold no SOC 2 report, no ISO 27001 certification, and no third-party security audit or penetration test report. Nothing on this page or anywhere else in our material should be read as implying otherwise. If a compliance attestation is a requirement for you, we do not have one today, and we would rather you knew that before you signed up than after.
6.2 No system is perfectly secure, and we do not claim this one is. What we claim is that the measures above exist in the shipped code, and that we would rather describe them precisely than decorate this page with badges.
7. Accountability
7.1 A comprehensive audit trail records who changed what: a business audit log of significant actions with the acting user and timestamp, and a forensic log of before-and-after row images maintained by database triggers. Section 3.8 of the Privacy Policy describes both layers and their retention honestly.
7.2 Breach notification commitments, including the 72-hour supervisory-authority window where the law requires it, are in section 13 of the Privacy Policy.
8. Reporting a vulnerability
8.1 If you believe you have found a security vulnerability, please report it to support@fiskwise.com. Include enough detail for us to reproduce the issue.
8.2 We will not pursue action against good-faith researchers who report privately, do not access data beyond what is needed to demonstrate the issue, and give us reasonable time to fix it before any disclosure.
This document is a first draft prepared for review by qualified legal counsel. It is not legal advice, it has not been reviewed by a lawyer, and it should not be published or relied upon until it has been.