Security, privacy, and how we treat your data.

Where we are right now

The product foundation was chosen for a financial product from day one: a managed database with encrypted storage, account-scoped access controls, row-level security policies on customer data tables, type-checked code paths from the API to the database, two-factor authentication encouraged on every account, data-model support for separately encrypted sensitive fields, and a deliberate read-only relationship with your brokerages.

The strongest protection is one we built into the product

Ironlake never moves money. We don't place trades, schedule transfers, or initiate any financial transaction, even if optional brokerage aggregation is added later. If you decide to trade, transfer, or rebalance, you do that outside Ironlake in the financial institution's own interface. A compromise of Ironlake cannot directly move money or place a trade, because there is no transaction path from our system into yours.

How the product is built

Three things matter most for a product that holds financial data: keeping each customer's data fenced off, encrypting it everywhere it sits, and validating every input before it reaches the database.

Account access

• Two-factor authentication is supported and strongly encouraged. Every account can enable two-factor authentication with a standard authenticator app.
• Passwords are never visible to us. They're hashed and salted at the authentication provider before storage. Even our own database administrators never see them.
• Sessions expire automatically. Sessions are short-lived and renewed on activity. Logging out invalidates the session immediately.

Data privacy

• We don't sell your account data. Not to marketers, not to affiliates, not as a side business. The product is funded by subscription, not by data. We use subprocessors to run the service. Anonymous browsing on our marketing pages goes through standard web analytics, and we keep an anonymous count of how many people complete each public calculator (no name or email, and no IP on the record itself - only a hashed, non-reversible IP key for rate-limiting) so we can see which tools are useful; authenticated dashboard pages collect Core Web Vitals performance metrics only (no behavioral analytics). If you arrive from one of our links or shared exports, we store a single first-party cookie (“il_from”) that remembers which page sent you, so we can see which of our own tools lead to signups. It holds only that source label (no name, email, or browsing history), and it clears when you create an account. While we're in early access, when a signup is turned away by the beta gate we keep a hashed, non-reversible record of the attempt by source (the email is stored only as an irreversible hash, never in plain text) so we can gauge how much demand the waitlist is holding back. If you submit the request-access form, the name and contact details you enter are sent to our CRM subprocessor (HubSpot), as described on that form, and we also keep the same hashed, by-source record. See the subprocessors section below.
• Trying the demo needs no account. The demo link gives your browser a temporary, anonymous session and a private copy of a sample household. There is no name, email, or password. The sample household, anything you change in it, and the session itself are deleted automatically 48 hours after you open it. We keep a hashed, non-reversible IP key to limit how many demos one address can open, an anonymous count of demo visits, and a minimal record that the Terms of Service, Privacy Policy, and Disclosures were accepted, with no name, email, or IP attached.
• You decide what happens to your data. The household owner can download a ZIP archive of the household's records from Privacy settings (once every 24 hours), with a manifest listing exactly what is included. Encrypted vault notes are not part of the archive; they stay readable in the vault. The owner can also request account closure there. Closure locks the household immediately, so copy anything you need from the vault first. It starts a sixty-day hold, so an accidental or unauthorized request can be reversed, after which the household's data is deleted. For corrections, records not in the archive, or any other request, email privacy@ironlake.co. Deletion covers the active application database, subject to legal, security, and backup retention requirements.

Subprocessors

The third-party services that touch your data. Each one is contractually bound to handle data on our behalf and is not permitted to use your data for any other purpose.

Incident response

If something goes wrong, you'll hear from us. We notify affected customers without unreasonable delay after confirming a security incident that involves their data, with a description of what happened, what data was involved, what we've done, and what you may need to consider.

To report a security concern or vulnerability, email security@ironlake.co. We aim to acknowledge reports within three business days. Responsible disclosure is appreciated and protected.

Legal documents

The versioned agreements and notices that govern the service: Terms of Service, Privacy Policy, and Disclosures. Each page shows the version and effective date of the text in force; your account records which versions you accepted.

Have a question we haven't answered, or want to talk through a specific control before submitting an access request? Email security@ironlake.co and we'll respond directly.