Information Security Policy

DanceLedger Information Security Policy

Effective Date: 2026-04-18 Version: 1.0 Owner: Abrazo Software LLC Contact: privacy@abrazo.dev

1. Purpose and Scope

This Information Security Policy ("Policy") establishes the security principles, controls, and practices that govern DanceLedger, a travel budgeting and expense-splitting platform operated by Abrazo Software LLC ("the Company"). The Policy applies to all systems, environments, applications, APIs, data stores, employees, contractors, and third-party services that process user data on behalf of DanceLedger. It covers the web application, mobile applications (iOS and Android), backend APIs, databases (MongoDB and PostgreSQL), object storage (S3), and all associated development and production infrastructure.

2. Data Classification

DanceLedger classifies data into four tiers based on sensitivity and regulatory exposure:

  • Public — Festival listings, marketing pages, published organizer profiles, and other information intentionally made available to unauthenticated users.
  • Internal — Aggregated usage analytics, non-identifying telemetry, and internal operational metrics used by the Company for product improvement.
  • Confidential — User personally identifiable information (PII) including name, email, password hashes, trip details, expense records, receipt images, bank account metadata, and financial transaction history.
  • Restricted — Authentication secrets (session tokens, TOTP seeds, OAuth refresh tokens), third-party API keys (Stripe, Plaid, RevenueCat, AWS, Anthropic), webhook signing secrets, and infrastructure credentials.

Access, transport, and storage controls applied to each tier are proportionate to its classification. Restricted data is never written to application logs, never returned in API responses, and never committed to source control.

3. Access Control

Access to user data and administrative functions is enforced through role-based access control (RBAC) using the shared UserRole enum (user, organizer, admin, superadmin). The Company follows the principle of least privilege: users, staff, and automated services are granted the minimum permissions required to perform their role.

All API endpoints are protected by AuthGuard unless explicitly marked @Public(). Subscription-gated endpoints (Plaid bank aggregation, unlimited AI plan generation) are additionally protected by ProTierGuard, which delegates entitlement checks to SubscriptionsService.isProUser() against the canonical Subscription table. Administrative endpoints (organizer-owned resource management, SuperAdmin dashboard, audit log access) are protected by OrganizerGuard and SuperAdminGuard respectively. Every sensitive action performed by an admin or superadmin is written to the AuditLog collection with actor, target, timestamp, and action metadata.

User isolation is enforced at the query layer: all database queries for user-owned resources filter by userId, and ownership is re-verified on every mutating operation (sync, remove, import, delete).

4. Authentication

DanceLedger uses better-auth for authentication, integrated into the NestJS backend via @thallesp/nestjs-better-auth. The following controls apply:

  • Email and password with a minimum password length of 8 characters.
  • Optional TOTP-based multi-factor authentication (MFA) via the better-auth TOTP plugin. Users may enroll from the Settings page; enrollment is offered but not required at first login.
  • Session tokens expire after 2 hours of inactivity and refresh automatically within a 1-hour refresh window.
  • Rate limiting of 100 requests per 10-second window applies to all authentication endpoints at /api/auth/*.
  • Administrative accounts (admin, superadmin) are created only via the backend seed script or SuperAdmin UI; self-service elevation is not permitted.
  • Recovery from a lost TOTP device is admin-assisted only: a SuperAdmin disables TOTP for the affected user through the SuperAdmin UI, which writes an audit log entry. No backup codes are issued.

5. Data Encryption

  • In transit: TLS 1.2 or higher is enforced on all external connections to the application, the API, and third-party services. HTTP-to-HTTPS redirects are configured at the edge, and HSTS is enabled on the web application.
  • At rest: MongoDB Atlas encrypts all data at rest using AES-256. PostgreSQL encryption at rest is provided by the managed database provider. S3 objects (receipt images) are encrypted with SSE-S3 server-side encryption. Plaid access tokens are stored in PostgreSQL and benefit from the same provider-level encryption at rest.
  • Secrets handling: All API keys, webhook secrets, and database connection strings are stored as environment variables sourced from a managed secrets store. Secrets are never written to source control, and .env files are excluded from the repository via .gitignore.

6. Vulnerability Management

The Company operates a continuous vulnerability management program:

  • GitHub Dependabot alerts are enabled on the monorepo and scan npm dependencies on every push.
  • The continuous integration (CI) pipeline blocks pull request merges on any critical-severity finding (CVSS 9.0 or higher). High and medium findings are reported in the pull request but are non-blocking.
  • Dependency updates follow the SLA: critical findings are remediated within 72 hours, high findings within 2 weeks, and medium findings within 30 days.
  • Static analysis and linting (ESLint with @nx/enforce-module-boundaries) run on every pull request.
  • Snyk and container image scanning are tracked for future adoption; the current coverage is considered sufficient for the platform's risk profile at this stage.

7. Incident Response

Detection is anchored by structured logging through the Winston logger and aggregated by an ELK (Elasticsearch, Logstash, Kibana) stack. The Company monitors:

  • Webhook delivery failures (Stripe, RevenueCat) via provider dashboards and backend 5xx rate alerts.
  • Subscription reconcile drift via the nightly RevenueCatReconcileService cron, which emits a SUBSCRIPTION_RECONCILE_SUMMARY structured log consumed by PagerDuty alerting rules.
  • Cron job liveness: absence of the reconcile summary for 25 or more hours triggers a PagerDuty alert.
  • Authentication anomalies, rate-limit exhaustion, and elevated error rates via Kibana dashboards.

When a suspected or confirmed security incident is detected, the on-call engineer follows the runbook at docs/runbooks/subscriptions.md for subscription-adjacent incidents and the general incident response playbook for other categories. The Company will notify affected users and, where applicable, the relevant supervisory authority within 72 hours of a confirmed personal data breach, consistent with GDPR Article 33 and applicable state laws.

8. Third-Party Services

DanceLedger depends on the following vendors. Each is evaluated for security posture before integration, accessed via dedicated API keys scoped to the minimum required permissions, and monitored for availability and incident disclosures.

  • Stripe — Payment processing and subscription billing. PCI DSS Level 1 compliant. Webhook events are signature-verified before processing.
  • Plaid — Bank account aggregation and transaction sync. SOC 2 Type II attested. Access tokens are user-scoped and revocable.
  • RevenueCat — Mobile subscription management for Apple IAP and Google Play Billing. Webhook events are authenticated via a shared-secret Authorization header and recorded in the WebhookEvent table for idempotency.
  • AWS S3 — Receipt image storage. Objects are encrypted at rest and served via short-lived presigned URLs (1 hour expiry).
  • Anthropic and Ollama — AI services used for trip planning. User financial data (expense amounts, bank transaction details, account balances) is never sent to AI providers. Prompts include only trip names, destinations, dates, and non-financial preferences.
  • Expo Application Services (EAS) — Mobile build and distribution.
  • MongoDB Atlas — Primary document store for users, trips, groups, festivals, chat history, and audit logs.

9. GDPR Compliance Baseline

DanceLedger is operated from the United States and is preparing for European Union availability. The following baseline applies today and will be expanded prior to EU launch:

  • Lawful basis for processing: Consent (account creation, optional feature opt-ins) and contract performance (delivery of the DanceLedger service).
  • Data controller: Abrazo Software LLC.
  • Data subjects: Registered users of the DanceLedger application.
  • Data subject rights: Right of access, right of rectification (via profile editing), right of erasure (see the Data Deletion Policy), right to restrict processing (on request via privacy@abrazo.dev), and right to data portability (planned for a future milestone).
  • Breach notification: The Company will notify the competent supervisory authority within 72 hours of becoming aware of a personal data breach likely to result in a risk to the rights and freedoms of data subjects, consistent with GDPR Article 33.
  • Records of processing activities: Maintained internally and reviewed annually, consistent with GDPR Article 30.
  • Data Protection Officer / Privacy Contact: privacy@abrazo.dev.
  • Sub-processors: A full sub-processor list and Data Processing Agreement (DPA) template will be published prior to EU availability.

10. Review Schedule

This Policy is reviewed at least annually and after any significant change to the system architecture, data flows, vendor list, or applicable regulation. Changes are versioned at the top of this document, and material changes are communicated to users via the product changelog and email notification where appropriate.

Back to DanceLedger