Security & trust

Last updated: August 28, 2026.

This page is for the person who has to decide whether their team's — or their client's — improvement projects can live here. It describes what LeanProjax does today, in plain terms, including the things we have notbuilt yet. LeanProjax is founded and operated by Nasser Al‑Sulaihim, an operational-excellence practitioner from the banking industry — a world where this question gets asked properly, which is why this page answers it the same way. If something below matters to your evaluation and isn't covered, ask us at info@leanprojax.com and we will answer directly.

Asking the individual’s version of this question — “can I use LeanProjax with my employer’s data?” — read using LeanProjax with work data: three safe paths, and a printable one-page memo for your IT team.

1. Where your data lives

The application, background workers, and the PostgreSQL database run on Railway managed infrastructure. All traffic to the web app, the admin console, and the API is served over TLS. Our providers may process data in the United States, the European Union, and other regions; the full sub-processor list and transfer safeguards are in the privacy policy.

2. Workspace isolation

Multi-tenancy is where a shared project tool either earns trust or fails, so it is enforced in three independent layers rather than one:

• Database.Every tenant-scoped table carries a deny-by-default PostgreSQL row-level-security policy, and the application's database role cannot bypass it. A query that forgets to name the organisation returns nothing rather than someone else's rows — it fails closed.
• Request.The active organisation is resolved from the caller's verified identity and checked against their membership on every request. A forged organisation header is rejected, not trusted.
• Project. Access to an individual assignment is checked against a role (lead, contributor, viewer) on top of organisation membership, with destructive actions requiring the higher ranks.

All three must agree for a request to succeed. We also run an automated cross-tenant probe suite against the live API that attempts to read and modify another tenant's data and fails the build if anything gets through.

3. Accounts & access

• Passwords are hashed with Argon2 and checked against known-breached password corpora at sign-up.
• Sessions use short-lived signed access tokens with rotating refresh tokens; reuse of a retired refresh token invalidates the whole session family.
• Repeated failed sign-ins trigger per-account backoff and a human-verification challenge, and every attempt is logged.
• You can see your active sessions and devices in settings and revoke any of them; deleting your account terminates all sessions immediately.
• Our internal admin console lives on a separate domain, is restricted to platform administrators, and requires TOTP two-factor authentication — there is no single-sign-on shortcut into it.
• Administrative actions and changes to your workspace are recorded in an append-only audit log.

4. Backups & recovery

The production database has a daily backup schedule plus point-in-time recovery(continuous write-ahead-log archiving), so a restore can target a moment rather than only last night's snapshot. We take an additional manual snapshot before any risky migration. Our internal recovery target is to be serving again within two hours of a catastrophic failure. Restores are performed to a new database instance, leaving the live one untouched.

5. How we build

• Every change runs through automated tests, type checking, static analysis (CodeQL), and secret scanning before it can ship.
• A weekly automated dynamic security scan runs against the live application; findings are triaged as work, not filed away.
• Dependencies are patched on disclosure — including out-of-band when a vulnerability affects us directly.
• Data-changing endpoints are covered by end-to-end tests that exercise the real authentication, authorisation, and validation stack.

6. Your data is yours

• We do not sell or rent your project content, we do not use it for advertising, and we do not train AI models on it.
• Projects export to PDF reports and Excel, so your work is portable out of the platform.
• Deleting your account removes or anonymises associated personal data within 30 days, except where law requires retention.
• A data-processing agreement is available on request for organisations that need one.

7. What we have not done yet

LeanProjax is in an active pilot, and being straight about the gaps is part of the deal:

• No SOC 2, ISO 27001, or comparable certification. We have not undergone a third-party audit. If your procurement process requires one, we are not ready for you yet — tell us, because it shapes what we build next.
• No third-party penetration test. Our security testing is automated and internal.
• No contractual uptime guarantee. We monitor availability continuously and publish incidents to affected customers, but the pilot carries no SLA.
• No customer-managed encryption keys or self-hosting option.

8. Reporting a vulnerability

If you believe you have found a security issue, email info@leanprojax.com with enough detail to reproduce it. We will acknowledge within two business days and keep you updated until it is resolved. Please give us a reasonable window to fix the issue before disclosing it publicly, and please do not access, modify, or retain data belonging to anyone else while testing.