Is your financial data safe in cloud property software?

Financial data in cloud property software is generally protected by access controls, encrypted transport, and encryption at rest, so the practical answer is yes, with one question left open: who holds the encryption keys. In most platforms the vendor does, which means your books are exactly as safe as the vendor's controls. Scaalr offers a stricter option: sensitive ledger fields encrypted behind a secret only you hold, which Scaalr cannot recover by design.

The question arrives at 4:40 PM on a Thursday, one line from a prospective owner's accountant: before we move the portfolio onto your software, who at the software company can read the books? Not whether the data is encrypted. Encrypted against whom. You have a security page bookmarked and a phrase in memory that sounds like bank-level, and neither answers the question as asked. It is a fair question, and it deserves a specific answer.

What encrypted at rest actually promises

Encryption at rest is the practice of storing data in encrypted form, so that a copied database or a stolen backup is unreadable without the keys. Nearly every serious cloud platform does it, and it is genuinely worth having: it protects against infrastructure-level theft, a mislaid backup, a decommissioned drive. Encryption in transit, the padlock in the browser, protects the same data while it moves. Both are table stakes.

What encryption at rest does not decide is who can read your data through the application. The application has to decrypt records to display them, and in the standard model it decrypts with keys the platform manages. Vendor staff with sufficient permissions can read customer data because, cryptographically, nothing stops them; policy stops them. Access rules, monitoring, and training are real safeguards, and reputable vendors run them seriously. They are also, from where you sit, promises.

That is the gap the brochure phrase leaves open. Bank-level encryption tells you a lock exists. It does not tell you who holds the key, and in most cloud software, property platforms included, the vendor holds it. Your books are then as safe as the vendor's controls, no less and no more.

Key custody: who can decrypt the books

Key custody is the question of who holds the material that turns stored ciphertext back into readable numbers, and it separates cloud platforms more sharply than any feature list. Three models cover the market. In the first, the platform manages the keys; this is the default nearly everywhere, and safety rests entirely on the vendor's controls. In the second, common in enterprise software, the customer controls keys through a managed key service: access narrows meaningfully, but custody still runs through infrastructure operated on the vendor's side.

In the third model, the customer holds the key. Customer-held-key encryption means the secret that decrypts the data is chosen by the customer and never leaves the customer's browser; the platform stores only the public key, which can lock data but never unlock it. There is no decrypting key on the vendor's side to misuse or leak, because it does not exist there.

Scaalr ships the third model for the books, as an option on Growth and up, under the plain name ledger encryption. Here is how it works.

How customer-held keys work in Scaalr

You turn on ledger encryption by choosing a secret, in your browser. A strength meter grades it, and a generator will produce a strong one if you prefer. From that secret the browser derives a key pair using Argon2id, a memory-hard key-strengthening algorithm, standardized in RFC 9106, built to make guessing slow and expensive. Only the public key is stored on the server; the private half exists wherever the secret does, and nowhere else. From that point Scaalr can lock your data and cannot unlock it. The cryptography underneath is modern public-key encryption (ECIES on P-256 with AES-256-GCM), and the pages where the key lives in the browser are guarded by a Content-Security-Policy.

Turning it on is deliberate by design. The enable step records your acknowledgment that Scaalr cannot recover the secret, because that condition is the trade that makes the protection real. Existing records then backfill: the encryption job is durable and resumable, survives server restarts, and never leaves the ledger half-encrypted.

Day to day, the books behave normally with one visible difference: without the secret, protected fields and any totals built on them display as locked. Enter the secret and the values reveal in place, without a full reload. A bookkeeper who should see everything enters it and works; a user who should not, does not. The double-entry ledger underneath is the same one covered in Property Management Accounting: The Complete Operational Guide.

The arrangement stays yours to change. Rotate to a new secret when a key holder leaves, or disable encryption entirely and decrypt the ledger back to normal storage. Readable, exportable books on your way out are part of the same posture argued in How to Switch Property Management Software Without Losing Your Books: records you cannot take with you were never fully yours. Ledger encryption sits on top of the platform's baseline controls, which are summarized on the security page.

What gets encrypted, and what stays readable

Ledger encryption is field-level by design, and the table below maps exactly what the customer-held key covers.

The split is deliberate. The amounts the system posts itself stay readable so financial reports keep totaling; any total that includes a manually entered amount stays locked until the secret is entered in the browser. The narrative fields carry the sensitive judgment: what an account is called, why an entry was made, what a variance reason admits. Those are the fields the key covers, including the notes and variance reasons recorded while matching the bank statement in the workspace covered by Bank Reconciliation for Property Managers: A Step-by-Step Guide. And one boundary is stated plainly rather than rounded up: bank-statement narrative is encrypted, but statement-line amounts are not yet encrypted end to end. Field-level protection of the sensitive fields is the honest description; whole-ledger encryption is not the claim.

On an encrypted account, the reporting layer respects the lock. Reports lock their totals and block export until the secret is entered, and owner statements detect figures they cannot unlock and refuse to produce an incomplete package, so a partial number never reaches an owner. That discipline matters most in the owner reporting covered in Property Management Reports: What Owners Actually Expect: the statement that goes out is complete, or it does not go out.

Turning it on: the enable flow

Enabling ledger encryption is a short procedure with one decision that deserves more thought than the clicks:

1. Decide who holds the secret. There is no vendor reset, so this is a business decision before it is a technical one: name the people who will hold the secret and agree where it is kept.
2. Choose a strong secret. The strength meter grades your choice, and the built-in generator will produce one worth keeping.
3. Acknowledge the no-recovery condition. Scaalr records your acknowledgment that the secret cannot be recovered or reset by the vendor.
4. Let the backfill run. Existing ledger records encrypt in a durable, resumable job that survives restarts and never leaves the books half-covered.
5. Work normally, unlocking when needed. Protected values display as locked until the secret is entered, then reveal in place.
6. Rotate or disable when circumstances change. Move to a new secret, or turn encryption off and decrypt the ledger.

Key questions

Can the software company see my financial data?

In most cloud platforms, yes, technically: data is encrypted at rest with keys the vendor manages, so authorized vendor staff can read it under the vendor's controls. That is the default architecture of cloud software, and reputable vendors govern it with access policies and monitoring. With Scaalr's ledger encryption enabled, the fields you encrypt are ciphertext to everyone without the secret, including Scaalr.

What happens if I lose the secret?

The encrypted fields stay locked, and Scaalr cannot reset or recover the secret. That is the design, and it is what makes the guarantee mean something: a vendor who can reset your key is a vendor who can read your books. Turning encryption on requires a recorded acknowledgment of exactly this condition, so decide who holds the secret and where it is kept before you enable it, not after.

Is this the same as bring your own key (BYOK)?

Same family, stricter custody. Bring your own key (BYOK) is the enterprise pattern where a customer supplies and controls the encryption keys for a vendor's platform, usually through a managed key service. Scaalr's customer-held keys go further: the secret is chosen in your browser and never leaves it, only the public key is stored, and no key service on the vendor's side holds anything that can decrypt.

Do reports still work with encryption turned on?

Yes. System-generated amounts, the entries that invoices, rent, and payments post, stay readable, so financial reports still total. Any total that includes a manually entered amount stays locked until the secret is entered in the browser. On encrypted accounts, reports and owner statements detect figures they cannot unlock and block the export, so a partial number never leaves the system.

Which Scaalr plan includes ledger encryption?

Growth and up. Growth is $99 a month for the first 50 units, then $1.49 per additional unit, and ledger encryption is included. The tier gates turning encryption on; an account that already holds a key can always read, rotate, or disable it. The rest of the accounting suite, the ledger, bank reconciliation, and financial reports, is on every plan, including Starter.

The Thursday email, answered

The accountant's question gets a reply that fits in four sentences: the sensitive fields in the ledger are encrypted behind a secret only this office holds; the software company stores a public key that can lock data but not unlock it; there is no recovery path through the vendor, by our own deliberate choice; and a report that cannot be fully unlocked does not leave the system. No adjectives, just custody. It is the answer the question was looking for.