Security overview

Summary

NeighborlyEvents is a hosted web and mobile service for community events. Sign-in is passwordless, card numbers never touch our servers, we run no advertising or third-party analytics, and the data your community puts in belongs to your community. This page states what we do and do not do so that a security review can be completed from it; the vendor questionnaire at the bottom answers the standard questions row by row.

Authentication and sessions

• Members sign in without passwords. The website sends a single-use, expiring sign-in link; the mobile app sends a six-digit code that expires in ten minutes and is cancelled after five wrong attempts. No password is stored for these accounts.
• Organizers may also set a password. Passwords are stored as bcrypt hashes. Sign-in attempts are throttled per account and per source address.
• Web sessions are HTTP-only, secure cookies that expire after 30 days.
• Mobile sessions use a short-lived access token (30 minutes) with a rotating refresh token; both are stored only as SHA-256 digests, and a device can be signed out remotely.
• Administrative access to the platform is limited to NeighborlyEvents staff accounts with an admin flag; organizer consoles are scoped to the community or club the organizer belongs to.

What we collect, and what we don't

We collect what the community needs to run itself: name, email address, an optional phone number, and — where a community verifies residency — a home address. Organizers may add custom registration questions. We do not collect card numbers (Stripe does), we do not sell or share personal data for advertising, and neither the website nor the app contains third-party analytics or advertising trackers. The Privacy Policy has the complete statement.

Encryption

• In transit. TLS on every connection, with HTTP Strict Transport Security; plain HTTP is redirected.
• At rest. The database (Supabase) and file storage (Amazon S3) encrypt data at rest at the storage layer; the database's daily backups are encrypted the same way. Third-party API keys that communities supply are additionally encrypted at the application layer. Personal fields such as email addresses and home addresses are stored in the encrypted database but are not additionally encrypted at the application layer, because the application searches on them.

Payments

Payments are processed by Stripe. Card details are entered into Stripe's own components and go directly to Stripe; NeighborlyEvents stores only Stripe's identifiers and the amounts. Organizers receive money through their own Stripe Connect account, and NeighborlyEvents never holds bank account details. See How the money works.

Hosting and subprocessors

The service runs on Amazon Web Services (US West) with a Supabase-managed PostgreSQL database in the same region, behind Cloudflare. The providers below process data on our instructions to deliver their function. We will update this list, with a note in the change history, before adding a provider that handles personal data.

Access control and auditing

Every organizer console is scoped to one community or club; an organizer of one community cannot read another's data. Registration state changes are logged with who made them and when. Platform administrators can act as an organizer for support, and that impersonation is visible in the interface while it is active.

Application security practices

• Static security analysis (Brakeman) runs in continuous integration and again as a gate in the deploy script; a finding blocks the deploy.
• The application runs on supported, current versions of Ruby and Rails, and dependencies are kept current.
• Security headers are set on every response (HSTS, X-Content-Type-Options, Referrer-Policy, Permissions-Policy). A Content Security Policy is deployed in report-only mode while its allowlist is tightened toward enforcement.
• Sign-in, sign-in-link requests, verification codes and anonymous form submissions are rate-limited.
• Uploaded financial documents are stored in a private bucket and served only through authenticated, streamed downloads — never by public URL.

Policies and runbooks

The internal policy set is written down and versioned with the application's source, reviewed at least annually, and available to customers on request:

• Information security policy — scope, ownership, and how the set is reviewed and changed.
• Access control — who can reach production systems and customer data, how accounts are protected, and how access is removed.
• Change management — every change ships through version control and a pipeline that runs static security analysis, dependency audits, linting and the test suite before deploy.
• Secrets management — encrypted credentials, who holds the keys, and rotation.
• Vulnerability management — scanning, triage timelines by severity, and coordinated disclosure.
• Incident response — detection, severity, containment, customer notification within 72 hours, and the post-incident report.
• Backup and recovery — cadence, retention, the restore procedure, and how often it is tested.
• Data retention and deletion — what is kept for how long, and how deletion requests are honored.
• Vendor and sub-processor management — selection criteria, the published list, and advance notice of changes.
• Acceptable use and device security — the standards the operator's own equipment and accounts meet.
• Business continuity — the continuity memo's commitments and the runbook behind them.

Backups and continuity

See the Continuity memo for hosting, backup cadence, the most recent restore test, data export and wind-down commitments.

Incident response

We will notify affected customers without undue delay and within 72 hours of confirming a personal-data breach, with what happened, what data was involved, and what we are doing about it. Operational alerts — errors, delivery failures, payment disputes, unusual database load — page the operator in real time.

Compliance posture

• SOC 2. NeighborlyEvents is not SOC 2 certified. The controls described on this page are documented and in operation; a formal audit is planned when customer volume warrants it.
• Privacy law. Members can request a copy or deletion of their personal data; account deletion is self-serve in the mobile app and by request on the web.
• Data processing addendum. Available. The standard template is published at /dpa; we execute it with the community on request.
• Insurance. NeighborlyEvents does not currently carry technology errors-and-omissions or cyber liability insurance and cannot provide a certificate of insurance. Coverage will be bound before or at the first paid community agreement; ask and we will confirm the timeline.

Reporting a vulnerability

Please report security issues to [email protected] (also published at /.well-known/security.txt). We acknowledge reports within two business days and ask for a reasonable window to fix before public disclosure.

Vendor security questionnaire

The standard questions, answered for NeighborlyEvents as it is today. "Partial" and "No" answers are stated as such — an honest gap is more useful to a reviewer than a soft yes.

Organization and policies

Access control

Data protection

Application security

Infrastructure and availability

Incident response and continuity

Privacy and compliance