Terms · Privacy · Subprocessors · Security · AI · Acceptable use · Accessibility · DPA · Français

Security

Version 1.0 · Effective 2026-08-20 · Last updated 2026-08-20

This page states how LobiSolutions protects the data you put into LobiPlan, what we do not do, and how you can check each claim for yourself. It applies to both Organization and Household workspaces.

1. Read this first: what we do not have

LobiPlan is built and operated by a small Canadian team. Publishing a security page invites you to assess us, so we start with the gaps rather than bury them.

If any of these is a hard requirement of your procurement policy, tell us now. We would rather say so plainly than consume your review cycle.

How to read the rest of this page. Every claim below is marked:

• [A] Architectural — a property of the code or the database schema. It holds because of how the system is built, and most of them you can verify yourself.
• [O] Operational — it depends on a person continuing to do it. Discount these from a small company; you would be right to.

2. Tenant isolation and architecture [A]

• Every table in the application database has row-level security enabled — currently all ~153 of them. We re-check after every schema change using our database vendor's own advisor tooling.
• Membership and administrator rights are resolved by two database functions, is_org_member and is_org_admin, named inside the policies themselves. The isolation rule is enforced by Postgres, not by application code that could skip a check.
• Writes go through SECURITY DEFINER procedures rather than direct table writes, so a client talking to the database directly cannot bypass a rule.
• Money — salaries, deal values, asset costs, budgets, household bank data — lives in tables with no policies at all and the table grant revoked, reachable only through administrator procedures. Row-level security alone is one barrier. These have two.
• Schema changes are append-only. Each is a new numbered file, and applied files are never edited. Our security posture therefore has a timestamped, version-controlled timeline you can read rather than a narrative you have to believe.

3. Access control inside the product [A]

4. Independent adversarial assessment [O, dated]

On 26 July 2026 we ran a structured adversarial security assessment across seven domains — Postgres authorization, unauthenticated attack surface, providers and supply chain, authentication lifecycle, browser-side, AI and agentic, and data protection — with a second reviewer whose instruction was to refute each finding. Two findings were refuted and are recorded as refuted.

Tenant isolation held. No path was found by which one customer's data is readable or writable by another, and none by which an unauthenticated visitor reads anything. The findings clustered in a different class — the platform trusting its own callers — and were remediated in schema changes 0243–0249 and 0266–0272.

This was an internal exercise, not a third-party audit and not a penetration test. The full report is a map of our system, so we do not publish it; it is available to customers and prospects under NDA.

5. Staff access to your data [A]

This is the question we are asked most often, and it is the one we can answer structurally rather than with a policy you would have to take on trust.

LobiSolutions staff hold no standing access to any customer workspace. The two database functions that decide membership and administrator rights do not recognise platform staff. That exemption was removed in schema change 0126, and its absence is re-verified in each assessment.

Our platform console shows operational metadata only: which tenant, what kind of action, when. It does not carry item names, note text, message content or chat content.

Yes, an operator can obtain access — and here is exactly what happens when they do. A support engineer who could never reach a customer's workspace could not support the product. So access is available, and it has three properties:

1. Deliberate. An operator must join your workspace, which inserts a real membership row under their own identity. There is no ambient access and no impersonation mode.
2. Visible. They appear in your member list, under their own name, and the join is written to your administrator audit log — which you read yourself at Admin → Activity.
3. Reversible. Leaving removes the membership.

Check it yourself. Open your administrator audit log. If we have ever joined your workspace, there is a row. An invitation to check is the only part of a security answer that is not itself a claim.

Two limits we would rather state than have you find:

• The audit log records the join, not everything done afterwards. Once joined, an operator is an administrator, and their subsequent actions appear in the work-event trail like any other member's. That is good, and it is a different claim from "we log every access". We are making the accurate one.
• Infrastructure credentials exist, as they must for anyone who runs a database. Whoever holds the Supabase project credentials can query the database directly, outside row-level security. This is true of every company that operates a database, including every SOC 2 holder — there the control is procedural rather than architectural. What we have removed is the ability to reach your data through the application without appearing in your own records.

6. Where your data is [A] for residency, [O] for the vendors

Application data is stored in Canada, in Supabase's ca-central-1 region.

The LobiPlan web application is a static client-side application with no server-side rendering, so page requests served from Vercel's global edge carry no customer database content — your browser talks to the Canadian database directly. Vercel sees request metadata: IP address, headers, paths.

Some processing necessarily happens outside Canada. Our AI provider, email provider, payments provider and bank-connection provider each run their own infrastructure. We will not tell you "your data stays in Canada", because it is not true and you would catch it. Subprocessors names every company, what it receives and where it runs.

⚠ [TO CONFIRM: the execution region of Supabase Edge Functions, several of which handle financial documents. If they are not region-pinned this section needs a further clause.]

7. Encryption [A] in transit, [O] at rest

In transit: TLS everywhere. HSTS is set to max-age=63072000; includeSubDomains; preload — two years, with preload. One curl -I confirms it.

At rest: encryption is provided by the underlying platforms, Supabase and AWS, and the keys are held by them, not by us. We deliberately name no cipher and no key length: if we do not manage the key, we should not describe the algorithm as though we chose it.

8. Retention and deletion [A]

Deletion runs on a schedule, per class of data.

Four classes are deliberately unbounded, and the reason matters:

The deletion mechanism, because it is a real control: a stored record and a stored file are two different things. Our sweeper deletes the object first and clears the pointer second. Reversed, a failure would leave an orphaned file — still present, still billable, no longer findable. This way a failure leaves a findable file.

Exporting. Every account holder can export their own data, self-serve, once per 24 hours, in 21 sections. Credentials — push subscription keys, calendar feed tokens, verification tokens — are excluded by design, and the export says so in a _meta.excluded block: it records the fact of a device or a feed, never the secret. Every field is named explicitly; there is no wildcard serialization.

Erasure of an account holder is by anonymisation, not deletion. Deletion was never available: 51 foreign keys point into the profile table and those pointers are the audit trail and the approval record. The profile is scrubbed, the sign-in disabled and private data deleted; approvals, history and the ledger survive with the name replaced by "Former member". A re-runnable check asserts that the anonymisation routine performs no deletion against approvals, approval history, work events, work items, messages or either ledger. This is performed by us on request today — there is no self-serve delete button. See the Privacy Policy.

Leaving entirely. Complete tenant deletion removes the organization and its data. It requires re-authentication with the administrator's email and password.

9. Your data and AI [A] on the perimeter, [O] on the vendor terms

• Every AI action is a proposal a person confirms. Automatic application is off by default, is set per user, and external email is never automatic under any setting.
• The AI cannot approve, reject or request changes on anything. The database procedure raises AI_ACTION_FORBIDDEN on those verbs. This is enforced in Postgres, not asked for in a prompt.
• The AI may propose prose, structure and transcription. It may not originate numbers, money, people or governance state.
• Payloads sent to the model are allow-listed by key. ⚠ One surface is not yet clean: the Capacity screen still sends colleague names to the model. The Dashboard payload was scrubbed of names; Capacity has not been. We are closing it.
• Model provider: Anthropic. There are per-user, per-organization and platform-wide call and spend ceilings.
• Images sent for receipt, pantry and recipe reading are read and discarded, never stored. Household bank statement PDFs are stored for ~30 days.

On training: we do not train models on your data, and we never sell it. Our AI provider is Anthropic, and under their API terms your content is not used to train their models. What every other company we use receives, and what they may do with it, is on Subprocessors. We will not make an unscoped promise on nine other companies' behalf.

See How LobiPlan uses AI for the full description.

10. Reporting a vulnerability [O]

Email bsimba6@gmail.com. Please include enough detail to reproduce the issue. We will acknowledge within 3 business days and give you an assessment and a remediation plan within 10 business days. We will keep you informed until it is resolved and, with your permission, credit you.

Safe harbour. If you make a good-faith effort to comply with this policy, we will consider your research authorized, we will work with you to understand and resolve the issue quickly, and we will not pursue or support legal action against you. If a third party brings action against you for activity conducted under this policy, we will make it known that it was authorized.

In scope: lobiplan.com, app.lobiplan.com, and the LobiPlan application.

Out of scope: denial of service, social engineering of our staff or customers, physical attacks, spam or automated scanning volume, and any testing against a live customer's workspace or data. If you need an account to test with, ask and we will create one.

Please do not access, modify or retain data belonging to anyone other than yourself. Stop as soon as you have confirmed an issue, and give us a reasonable opportunity to fix it before disclosing publicly.

We do not run a paid bug bounty.

11. Incident and breach notification [O]

If we become aware of a breach of security safeguards affecting your personal information, we will record it, assess it, and — where there is a real risk of significant harm — notify you and the Office of the Privacy Commissioner of Canada as soon as feasible.

If you are an Organization customer, we will notify you without undue delay and in any event within 48 hours of confirming a breach affecting your workspace. Notice goes to your designated contact by email and to your administrators in the application. It will say what happened and when, the categories of data involved, who is affected as far as we can determine, what we have done, what we recommend you do, and who to contact.

Three things we want to be precise about:

• The clock starts at confirmation, not at an anomaly. A trigger we cannot start is a promise we cannot keep.
• We do not promise 24 hours. Buyers ask for it. A small team cannot honour it reliably, and a missed notification clause is a contract breach stacked on an incident. 48 hours still leaves an Organization customer 24 hours of their own 72-hour regulatory window.
• A first notice is necessarily incomplete. We commit to updating you as facts are established rather than delaying notice until they are.

We keep a record of every breach of security safeguards for at least 24 months, whether or not it meets a reporting threshold, and we will produce it to the Privacy Commissioner on request.

We need somewhere to send this. Organization customers should give us a designated security and privacy contact.

12. Past security findings

We would rather tell you than have you discover we did not. We have had no breach of customer personal data. We have self-identified and remediated two findings we consider material enough to disclose:

1. A storage bucket holding profile photographs was publicly readable at a predictable path. It was made private, paths were randomized, and access moved to time-limited signed URLs. We measured the residual exposure window in the content delivery cache and it was bounded.
2. A legacy database trigger, created outside our version-controlled schema, carried a shared secret in cleartext in the database catalogue — and therefore in backups. The trigger was removed and the secret rotated. This is a credential exposure, not a personal-data exposure.

Neither is known to have been exploited. Both are described in the assessment we share under NDA.

13. Availability [O]

We do not currently offer a contractual uptime commitment, and we publish no uptime figure. There is no monitoring in place, so any number we published would be unverifiable. Business plans are sold by agreement and availability terms can be discussed.

14. Application and platform hardening [A], gap included

Both hosts send, and you can check with one request:

The marketing hosts run a full content security policy with inline scripts pinned by SHA-256 hash rather than unsafe-inline, and the site loads no third-party resources at all — fonts are self-hosted, and there are no analytics, no tag manager and no tracking pixels.

⚠ The gap, in the same section rather than omitted: the application host at app.lobiplan.com currently sets frame-ancestors only. It does not yet restrict what the application may load or connect to. We are rolling that out in report-only mode first. (Last updated: 2026-08-20.)

Sessions. Authentication is JSON Web Token, approximately one hour, with refresh-token rotation. Tokens are held in browser localStorage, which is the standard Supabase browser configuration — they are not httpOnly cookies, and we would rather say so than have you ask. The compensating controls are the short token lifetime, the rotation, frame-ancestors 'none' plus X-Frame-Options: DENY against framing, and no third-party scripts on the application origin. Sign-out is scoped to the local device deliberately.

Passwords. We never hold them; they are managed and hashed by Supabase Auth. A password change requires the current password. The application enforces a minimum of 8 characters. ⚠ [TO CONFIRM: the authoritative Supabase Auth password policy — length, complexity, breached-password rejection and rate limiting — which is configured in the dashboard rather than in the repository.]

Storage. Buckets are private and accessed through time-limited signed URLs.

15. Development practice [O], and the separation-of-duties answer

We would rather state the constraint than have you derive it. LobiPlan is developed by a small team without a separate reviewer for every change. We compensate structurally:

• Schema changes are append-only and never edited after application.
• 2,460 automated tests across 85 files run on every change, and several of them assert against the shipped artefact — parsing the built stylesheet or the migration files themselves — rather than re-importing the code under test.
• Our database vendor's security advisor runs after every schema change and currently reports zero ERROR-level findings, with four categories held at zero and the single documented exception named explicitly.

⚠ [TO CONFIRM: whether the operator accounts on the production consoles — Supabase, Vercel, Stripe, AWS, Anthropic, Resend, GitHub and the domain registrar — have multi-factor authentication enabled, and the date each was confirmed.]

⚠ [TO CONFIRM: the Supabase backup tier in force, whether point-in-time recovery is enabled, and the date of the last documented restore test. We have not yet performed one.]

16. Frequently asked

Are you SOC 2 audited? LobiSolutions holds no SOC 2 Type II report and no ISO 27001 certificate, and we will not imply otherwise. We are a small Canadian company; a Type II report needs a continuous observation window we have not yet run and an auditor we have not yet engaged. What we offer instead is evidence you can check rather than an attestation you have to trust:

1. A dated adversarial security assessment (26 July 2026, seven domains, with a second reviewer whose job was to refute each finding). It records what was found, what was refuted, and twelve accepted risks with the reason each was accepted. Available under NDA. It is an internal exercise, not a third-party audit.
2. An append-only change history. Every schema change is a new numbered file and applied files are never edited, so our posture has a timestamped timeline you can read. That is a stronger claim about continuity than a point-in-time sample.
3. Automated gates that assert against what actually ships — 2,460 tests across 85 files, several of which parse the built stylesheet or the migration files themselves.
4. Third-party static analysis on every schema change — our database vendor's security advisor, currently zero ERROR-level findings.
5. A live verification session. We will screen-share and run the checks you nominate against our production database — that every table has row-level security, that our platform-administrator functions grant no tenant access — and you can watch the query and the result.

If a SOC 2 report is a hard requirement of your procurement policy, please tell us now.

Do you support multi-factor authentication? No. Not for customer accounts, and there is no date we are willing to commit to here. Compensating: we never hold your password, sessions are short-lived with refresh-token rotation, and a password change requires the current password.

Do you support SSO or SCIM? No, and not planned at our current size. Compensating: administrator-managed membership with a seat cap; a single removal action that unassigns work, clears role tiers and offboards the HR record in one transaction; and an audit log of every membership change that you read yourself.

Do you have a formal joiner/mover/leaver process for staff? No. LobiPlan is operated by a single person, so there is no staff access to provision or revoke. When we hire, this becomes a control and we will publish it.

Can we get a DPA? Yes. See the Data Processing Addendum, offered to Organization customers.

17. Contact

Security questions, vulnerability reports and questionnaire requests all go to the same place: bsimba6@gmail.com. It is one address, monitored by a person, and it is the only one we publish.

Related: Privacy Policy · Subprocessors · Data Processing Addendum · How LobiPlan uses AI · Terms of Service

Changes to this document

We notify material changes in advance, by email and in the application. Non-material corrections are noted below. Previous versions are available on request from bsimba6@gmail.com.

LobiPlan for organizations · LobiPlan for households · bsimba6@gmail.com