BenefitsSafeBenefitsSafe

Version 1.0 · Last updated April 21, 2026

Security at BenefitsSafe

Nonprofits trust BenefitsSafe with Beneficiary Social Security Numbers, benefit-program enrollment data, and the grant funds that keep vulnerable people housed and fed. This page describes the specific technical and organizational measures we use to protect that information. Every claim below is implemented in the current production codebase and is referenced by Section 4 of our Data Processing Agreement and Section 10 of our Privacy Policy.

What we do — and what we don't

We are deliberate about the difference between "implemented today" and "on the roadmap." Legal teams reviewing this page should treat the first list as current fact and the second list as planned future state.

In place today

  • AES-256-GCM encryption at rest for sensitive Beneficiary fields (SSN, DOB, full addresses) at the application layer, on top of the AWS Aurora native storage encryption.
  • TLS 1.2 or higher enforced on every public endpoint. HTTP Strict Transport Security is set with max-age=63072000 (2 years), includeSubDomains, and preload.
  • Multi-factor authentication (TOTP) available for every user and required for administrative and platform-staff accounts.
  • Session fingerprinting (hashed IP + User-Agent) to detect session-cookie theft, with automatic flagging on sensitive routes.
  • Rate limiting on authentication, registration, password reset, and financial endpoints using Upstash serverless Redis.
  • Immutable application audit logs (every data mutation records actor, timestamp, before/after values) retained for two years.
  • Organization-scoped queries enforced by middleware, auth guards, and a convention linter that blocks merges if a route accesses session.user.role directly or skips the org-scoping helper.
  • Content Security Policy with frame-ancestors 'none', Cross-Origin-Opener-Policy, Cross-Origin-Resource-Policy, X-Content-Type-Options, X-Frame-Options, Referrer-Policy, and Permissions-Policy headers on every response.
  • Circuit breaker and per-call timeout budget on outbound Stripe API calls to prevent a slow upstream from exhausting serverless concurrency.
  • OFAC SDN sanctions screening on every Beneficiary before a card is issued, plus periodic re-screening. Screening failures fail closed — a transient OFAC outage blocks issuance rather than allowing it.
  • Real-time Merchant Category Code (MCC) controls on virtual-card authorizations to protect SSI / Medi-Cal / CalFresh eligibility.
  • npm supply-chain hardening: .npmrc sets ignore-scripts=true to prevent malicious postinstall scripts from running during npm install. Dependency vulnerability scans run on every build.
  • SPF, DKIM, and DMARC configured on benefitssafe.com to prevent outbound email spoofing.
  • Secrets are stored in AWS Secrets Manager and exposed to production runtimes via encrypted environment variables — never committed to the repository.
  • S3 buckets are configured with no public access; bucket policies require encrypted transit (TLS) and AES-256 encryption at rest.
  • AWS CloudTrail records all AWS API activity with KMS-encrypted log delivery.
  • Code reviews against the OWASP Top 10 checklist before every production deployment.

Not in place today (planned or out of scope)

  • SOC 2 Type II certification is in progress. Target completion: Q3 2026. Until we hold the report, we share a NIST-Cybersecurity-Framework-aligned security-program letter on request.
  • ISO 27001 certification is not currently pursued.
  • PCI DSS certification is not applicable to BenefitsSafe at the platform level — we do not store, process, or transmit primary account numbers. Card data is handled exclusively by Stripe, which holds PCI DSS Level 1 certification.
  • HIPAA: BenefitsSafe is not currently a HIPAA Business Associate. If a Nonprofit's specific use case requires us to handle Protected Health Information, contact privacy@benefitssafe.com to discuss a Business Associate Agreement before uploading PHI.
  • Third-party penetration testing is scheduled for post-launch in Q3 2026. Interim assurance comes from internal security reviews and dependency-CVE scanning.
  • 24/7 Security Operations Center: BenefitsSafe is currently a solo-founder operation. High-severity alerts (from Sentry, Better Stack, and AWS CloudTrail) are routed to an on-call channel that is monitored continuously; non-critical alerts are triaged during business hours in Pacific Time.
  • Public bug bounty program is planned for Q3 2026. In the meantime, coordinated disclosure is welcomed at security@benefitssafe.com.

Data encryption

  • At rest: AES-256-GCM at the application layer for sensitive Beneficiary fields (SSN last 4, DOB, full addresses). AWS Aurora native storage encryption (AES-256 via AWS KMS) covers the entire database and all automated backups.
  • In transit: TLS 1.2 or higher on every connection; HSTS preloaded with a 2-year max-age.
  • Key management: AWS KMS with key rotation policies enabled on the customer-managed keys.
  • Secrets: AWS Secrets Manager with least-privilege IAM policies. No secrets in source control.

Access control

  • Role-based access control across twelve distinct roles (nonprofit_admin, nonprofit_staff, beneficiary, cpa, auditor, attorney, grant_officer, compliance_officer, support_agent, billing_admin, vendor, platform_admin).
  • Organization-scoped queries are enforced at the middleware and data-access layers. Cross-organization reads require an explicit platform-admin breakglass path that is separately audited.
  • MFA (TOTP) available for every user, required for administrative and platform-staff roles. Backup codes are stored hashed.
  • Session lifetime: 1 hour of inactivity; session token refreshed every 15 minutes of active use. Session cookies are HttpOnly, Secure, SameSite=Lax, and use the __Secure- /__Host- prefixes in production.
  • Login rate limiting (5 attempts per IP per minute) and per-email login limiting to resist credential stuffing.

Infrastructure security

  • Hosted on AWS (us-west-2 primary, us-east backup) and Vercel for edge delivery. DNS and proxy for app.benefitssafe.com are served by Cloudflare.
  • S3 buckets locked down: no public access, encryption-in-transit policy required, server-side encryption enforced.
  • AWS CloudTrail captures API activity with KMS-encrypted log delivery.
  • Database backups are encrypted and retained per the IRS 7-year financial-records rule.
  • Disaster recovery: AWS Aurora multi-AZ deployment with automatic failover. Recovery Point Objective (RPO): 1 hour. Recovery Time Objective (RTO): 4 hours.

Application security

  • Every HTTP input is validated at the API boundary with Zod schemas; every database query is parameterized via the Prisma ORM (SQL-injection-safe by construction).
  • Every route mutation generates an immutable AuditLog record (actor, organization, entity type/ID, before/after values, IP).
  • Dependency CVE scanning runs on every build. Critical-severity advisories are remediated within 7 days; high within 30 days.
  • .npmrc sets ignore-scripts=true to neutralize malicious postinstall scripts from transitive dependencies. BenefitsSafe verified non-exposure to the March 2026 npm supply-chain incident involving axios.
  • OWASP Top 10 review is part of the pre-merge checklist for every pull request that touches auth, money, or data access.

Multi-tenancy and data isolation

BenefitsSafe is designed for the ~1.9 million US 501(c)(3) nonprofits with zero cross-organization data leakage. Isolation is enforced at the database-access layer, not just the UI:

  • Every Prisma query that reads Nonprofit-scoped data is written through a helper that injects organizationId into the where clause. Direct access via session.user.role is blocked by the auth-guard convention linter.
  • API routes that must read across organizations (for example, platform-admin reports) use an explicit breakglass path that writes a distinct AuditLog entry for every cross-org read.
  • Webhook handlers look up the affected organization from the external identifier (Stripe account ID, subscription ID) before mutating any data, and reject events for unknown accounts.

Payment and card data security

  • BenefitsSafe does not store primary account numbers, card numbers, CVVs, or bank-account routing numbers.
  • Card data is handled end-to-end by Stripe (PCI DSS Level 1 certified). Virtual cards are issued by Sutton Bank and Evolve Bank & Trust, Members FDIC, via Stripe Issuing.
  • Nonprofit bank-account onboarding is handled through Stripe Connect's native flow; BenefitsSafe receives only the tokenized bank reference and the last four digits of the account.
  • BenefitsSafe is out of PCI DSS scope at the platform level because it does not touch cardholder data.

Beneficiary privacy protections

  • Beneficiary PII (SSN, DOB, full address) is encrypted at rest with AES-256-GCM at the application layer and never appears in list-API responses.
  • Access to Beneficiary records requires authenticated Nonprofit staff with an org-scoped role. Beneficiaries can access only their own data.
  • OFAC sanctions screening runs on every Beneficiary before card issuance and periodically thereafter. Stale screens (older than 30 days) fail closed at the card-authorization step.
  • Beneficiary benefit-program enrollment data (SSI, SSDI, Medi-Cal, CalFresh, ABLE) is used only for the compliance engine's risk classification; it is not shared with third-party advertisers, data brokers, or government agencies except under lawful process.
  • Real-time MCC controls on Stripe Issuing authorizations prevent transactions that would likely disqualify a Beneficiary from means-tested benefits.

Incident response

  • Detection: alerts from Sentry (application errors), Better Stack (log anomalies), AWS CloudTrail (API misuse), and Stripe (webhook/auth anomalies) are routed to an on-call channel. High-severity alerts page immediately; non-critical alerts are triaged during Pacific-Time business hours.
  • Containment: the on-call target is one hour from the time a high-severity alert fires.
  • Nonprofit notification: BenefitsSafe will notify the affected Nonprofit's privacy contact within 24 hours of confirmation of a Security Incident that affects their data. Contents of the notice follow DPA §7.2 and California Civil Code §1798.82.
  • Regulatory notification: where GDPR Article 33 applies, the Nonprofit (as Data Controller) is responsible for the 72-hour supervisory-authority filing; BenefitsSafe supplies the facts and cooperates.
  • Post-incident reports (what happened, what we changed) are shared with affected Nonprofits within 72 hours of containment.

Responsible disclosure

  • Report vulnerabilities to security@benefitssafe.com.
  • We commit to acknowledge reports within 5 business days and to keep researchers informed of remediation progress.
  • BenefitsSafe will not pursue legal action against good-faith security researchers acting within scope and without exfiltrating customer data.
  • A formal public bug bounty program is planned for Q3 2026.

Compliance alignment

  • GDPR: processor obligations under Article 28 are met via the Data Processing Agreement.
  • CCPA / CPRA: consumer rights are disclosed in the Privacy Policy §7.2. BenefitsSafe does not sell or share Personal Information as defined by CCPA.
  • GLBA: to the extent applicable, the Safeguards Rule (16 CFR Part 314) requirements for information security, MFA, encryption, and access control are covered by the controls above. Consumer GLBA privacy notices for cardholders are issued by the card-issuing banks.
  • EFTA / Regulation E: error-resolution and liability-limit procedures are disclosed in Section 14 of the Privacy Policy and administered by the card-issuing banks.
  • SSA POMS: the compliance engine applies federal SSI rules (and the California Medi-Cal / CalFresh overlay) to classify expenses before they can be authorized, so that Beneficiary eligibility is protected by default.
  • NIST Cybersecurity Framework: we map our controls to Identify, Protect, Detect, Respond, and Recover; mapping documentation is available under NDA.

Employee and contractor security

  • BenefitsSafe is currently a solo-founder operation. Production access is limited to the founder and, as the team grows, to expressly authorized personnel.
  • All future staff and contractors with production access will sign confidentiality agreements and be bound by the same data- protection obligations.
  • All production access is logged via AWS CloudTrail and reviewable on request.

Physical security

BenefitsSafe does not operate its own data centers. Physical security is inherited from AWS (SOC 2 Type II, ISO 27001, PCI DSS Level 1) and Vercel (SOC 2 Type II, ISO 27001). The company has no on-premise servers or employee workstations that store Beneficiary data.

Business continuity

  • Database backups: automated by AWS Aurora, encrypted, retained for 7 years per IRS financial-records requirements, integrity spot-checked quarterly.
  • Disaster recovery: multi-AZ Aurora deployment for automatic failover; point-in-time recovery enabled.
  • Target Recovery Point Objective (RPO): 1 hour.
  • Target Recovery Time Objective (RTO): 4 hours.

What Nonprofits can do

  • Enable MFA on every staff account.
  • Use strong, unique passwords managed by a reputable password manager.
  • Review your organization's AuditLog and active sessions in Settings at least monthly.
  • Revoke access for departing staff the same day; BenefitsSafe makes this a one-click operation in the Team settings.
  • Train staff on phishing awareness. Legitimate BenefitsSafe email always comes from a @benefitssafe.com domain and never asks for passwords or SSN.
  • Report anything suspicious to security@benefitssafe.com.

Contact

Version history

VersionDateChanges
1.0April 21, 2026Initial publication.