How we handle a community's data

Data isolation

Each community has its own database. One community's ledger, residents, and documents are not stored in the same tables as another's, so a query cannot cross between communities by accident. Access to a community database is granted per request after the signed-in user's membership in that community is checked.

Sign-in

• Staff sign in with an emailed six-digit code or password, depending on the workspace.
• Residents sign in with a six-digit code. Codes are stored hashed, expire after 15 minutes, and work once.
• Sign-in responses do not reveal whether an address belongs to a resident.
• Access changes — invites, role changes, removals — are written to an audit trail.

Credentials

Database credentials and signing keys are held in Azure Key Vault and injected at runtime. They are not stored in the application repository, and deployments authenticate to Azure through federated identity rather than a stored password.

Financial records

• Journal entries are never edited or deleted after posting; corrections are made by posting a reversal.
• Closing a fiscal year locks it. Reopening records who did it and when.
• Every community's books can be exported in full.

What we cannot claim yet

We have no SOC 2 report, no third-party penetration test, and no 24-hour incident response commitment. Rate limiting on sign-in endpoints is being added before the public pilot. If your board needs any of those to sign off, say so early — it is better to know before a contract than after.

Reporting a concern

Write to support@ourridge.com. We will confirm receipt and tell you what we found. Please do not post a suspected vulnerability publicly before we have had a chance to fix it.