A security page that lists only strengths tells you nothing, because every security page lists only strengths. This one names each independent check by title and states whether NetWorth+ has it. Several of the answers are no.
Independent validation
Where NetWorth+ actually stands
In short
NetWorth+ has not undergone an independent penetration test and holds no SOC 2 or ISO 27001 certification. That is the honest position of a small bootstrapped team and it is published here rather than left for someone to discover. What reduces the risk is architectural rather than procedural: the app has no open banking connection, collects no bank credential and cannot initiate a payment, so the material most worth stealing from a finance app is never present to steal. Bank alert SMS is read and parsed on the device and the message text is not uploaded. No full card number is ever stored, and sign-in runs on Firebase Authentication, so no password is stored by NetWorth+ at all. Access rules enforced on the server mean one account can only ever read its own records, rather than that restriction living in app code where a modified client could ignore it. Data is encrypted in transit and at rest on Google Cloud and Firebase infrastructure, which Google independently certifies to ISO 27001 and SOC 2, though that certification covers the platform and not the NetWorth+ application code running on it. Security reports go to [email protected] and are read before feature work.
SOC 2 / ISO 27001
Not held
Third-party pen test
None to date
Card numbers stored
None, ever
Passwords stored by us
None, Firebase Auth
The distinction
This is the single most misused claim in finance app marketing, so it is worth separating carefully.
NetWorth+ runs on Google Cloud and Firebase. That platform is independently certified to ISO 27001 and SOC 2, along with other standards, and audited annually by third parties on Google's side. Those certificates are real, and they are Google's.
They say nothing about whether the NetWorth+ application code is written well. A certified data centre will faithfully host an insecurely written app. Any company that answers a security question by naming its cloud provider's certifications is answering a different question from the one you asked, and you should treat it as a non-answer, including when we are tempted to do it.
Both are true at once. The second one is the gap, and no amount of the first one closes it. What we can do in the meantime is reduce how much a failure in our code would actually be worth, which is what the architecture section below is about.
Check by check
The list a due diligence reader works through, with our actual status against each line rather than a general reassurance.
| Independent check | Status today | What that means in practice |
|---|---|---|
| SOC 2 Type II | Not held | No auditor has tested our controls over a monitoring period. This is the standard a business buyer would normally require, and it is a real gap. |
| ISO 27001 | Not held | No certified information security management system. Achieving it is a process and cost commitment that a pre-revenue app has not made. |
| Third-party penetration test | Not commissioned | No external tester has attempted to break the app or its rules. Planned as an investment once revenue supports it. |
| Public bug bounty | Not running | No paid bounty programme. Reports are welcomed and read, but there is no reward pool behind them. |
| Vulnerability disclosure route | In place | A published address, a commitment to read security mail first, and a request for a reasonable window before public disclosure. Detailed below. |
| Published security overview | This page | The written account of architecture, data handling and known gaps that a reviewer would otherwise have to request by email. |
| Infrastructure certification | Held by Google | ISO 27001 and SOC 2 apply to the Google Cloud and Firebase platform. They are Google's certifications, covering the platform and not our code. |
This table is maintained as the position changes. If a penetration test or certification is completed, it will be recorded here with its date rather than announced only in marketing copy. Last reviewed August 2026.
Threat model
The strongest security property an app can have is not holding the dangerous thing in the first place. Four decisions do most of the work here.
NetWorth+ never asks for a bank username, password or open banking token, and has no aggregator integration. A total compromise of our systems yields no way into anybody's bank account, because that material was never collected.
The app cannot move money. It has no payment capability to abuse, so the highest value attack against a finance app, initiating a transfer, does not exist against this one.
Bank alert messages are read and interpreted on your phone. The message text is not uploaded, so there is no server-side store of your SMS to breach. The feature is optional, Android only, and off until you switch it on.
The restriction that an account can read only its own records lives in server-enforced access rules, not in app code. A modified or rebuilt client cannot argue its way past them, because it is not the client making the decision.
Blast radius
The useful question is not whether a breach is possible, it is what a successful one would actually be worth. Here is the honest inventory.
| Data | Reachable in a breach of our systems? |
|---|---|
| The ledger you built: accounts, balances, transactions, categories, budgets and goals | Yes. This is the substance of what NetWorth+ stores, and a breach would expose it. |
| Shared expense records and settlements with other people | Yes, for the records connected to the affected account. |
| The email address on your account | Yes. |
| Your bank username, password or any open banking token | No. None is ever collected, so none exists to take. |
| The content of your bank SMS messages | No. Message text is processed on the device and is not uploaded. |
| Your full credit or debit card number | No. NetWorth+ never stores a full card number. Card records in the app are the cycle, limit and due-date details you enter, not the card itself. |
| Your account password | No. Sign-in runs on Firebase Authentication and NetWorth+ stores no password. |
| The ability to move money out of any account | No. The app has no payment capability whatsoever. |
Stating this openly is deliberate. An app that will not tell you what a breach would expose is asking you to assume the answer is nothing, and it never is.
Responsible disclosure
There is no paid bounty, and pretending otherwise would waste your time. What there is: a real address, a fast read and credit where you want it.
Send the detail to [email protected] with enough information to reproduce the issue. Security mail is read before feature work.
Please allow a reasonable period to investigate and ship a fix before disclosing publicly. We will tell you what we find rather than going quiet.
Use your own account and your own data. Do not access another person's records, degrade the service for others, or run destructive tests.
If you would like to be credited for the report once it is fixed, say so and you will be. If you would rather stay anonymous, that is fine too.
NetWorth+ has a narrow attack surface by design and no independent validation of the code sitting behind it. A reviewer who concludes that this is good architecture with insufficient external verification has read the situation correctly, and that is the position we would rather publish than have inferred. If independent assurance is a hard requirement for you, that requirement is not met here yet, and you should weigh that before moving years of records into the app.
Questions
Keep reading
A finance app that never collects your bank credentials is protecting you in the one way that cannot fail. Everything else is a promise; that part is structural.
Android. No bank login. No ads. Message reading is optional and off until you switch it on.