Security Policy

Last updated: August 8, 2026

1. Infrastructure

HelmHOA runs on Google Cloud infrastructure via Firebase. All data is encrypted in transit (TLS) and encrypted at rest by Google Cloud's storage layer. Server-side functions handle every operation that involves sensitive credentials — API keys and integration secrets never reach the browser or the device. The application and this website are served with security headers including HTTP Strict Transport Security, clickjacking protection, and MIME-sniffing protection.

2. Authentication

Invitation-only onboarding: accounts are provisioned only against an invitation created by your community's management, with the invited role enforced at account creation — users cannot grant themselves roles.
Verified email required: an invited account does not activate until its email address is verified.
Sign-in options: email and password, Google sign-in, Sign in with Apple (iOS app), and passwordless email links for invited owners.
Multi-factor authentication: if you sign in with Google or Apple, that provider's own multi-factor protections apply to HelmHOA automatically — we recommend administrators enable them.
Session timeout: inactive sessions are warned and then signed out automatically after 30 minutes.

3. Access control

Access is enforced server-side by database and storage security rules — not just hidden in the interface:

Role-based access: owners see only their own units; inspectors and maintenance staff see only their assigned buildings (and, where configured, only specific units); building-scoped administrators see only their assigned buildings.
Per-association isolation: every record carries a community identifier, and every administrative read and write is scoped by it — one association's data is never visible to another's.
Owner write restrictions: owners can submit repair proof and move their unit only along the permitted status transition — all other status changes require administrative access.
Server-validated assignments: sensitive identity changes, such as linking an owner to a unit, are validated by server-side functions rather than trusted from the browser.
Granular admin permissions: separate permission flags govern managing users, deleting records, and other sensitive operations — and administrators can never modify their own permissions.

4. Accountability and integrity

Audit log: administrative actions — approvals, rejections, deletions, permission changes — are recorded with the actor and timestamp, and audit entries cannot be edited or removed by the people they describe.
Multi-admin deletion safeguards: destructive operations require confirmation from a second administrator, who must be a different person than the requester.
Status integrity: compliance status is computed by the system from approved repair items — it cannot be hand-edited into a false "compliant" state.

5. Application security practices

Input sanitization on free-text fields, aligned with OWASP guidance.
Upload validation: file type and size limits enforced on photo and document uploads.
Rate limiting on server-side functions, including the AI analysis functions.
Email normalization and constrained lookups to prevent account enumeration.
App Check request attestation is being rolled out in stages across the platform's backends.
Recurring security reviews of our security rules and authentication flows, with findings tracked to remediation.
Dependency management with locked versions and automated vulnerability alerts.

6. Data handling

Photos and documents are stored in access-controlled cloud storage, scoped by the same role rules as the database — files are not publicly accessible.
AI analysis happens server-side; see the Privacy Policy for what is shared with our AI provider and how it is used, and the AI Disclosure for where AI is and is not used.
Account deletion is available in-app, including on iOS; community records follow the association's retention decisions.

7. Availability

The platform is served from Google's global infrastructure with automatic scaling and redundancy. The field experience includes offline support — inspections queue locally and sync when connectivity returns — so field work isn't lost to a dropped connection.

8. Certifications and roadmap

HelmHOA is not SOC 2 certified today, and we won't imply otherwise. We maintain an active security roadmap building toward SOC 2 Type II readiness (Security, Availability, and Confidentiality criteria), and we are glad to walk a board's reviewer or attorney through our current posture — contact us for security questionnaires and vendor-review requests. A Data Processing Addendum is available on request.

9. Responsible disclosure

If you believe you've found a security vulnerability in HelmHOA, please report it to us privately at privacy@helmhoa.com with enough detail to reproduce the issue. Please don't access data that isn't yours, disrupt the service, or disclose the issue publicly before we've had a reasonable opportunity to address it. We're grateful to researchers who report in good faith and will acknowledge and act on valid reports promptly.