Information Security Policy

How Beneficiary.io protects the confidentiality, integrity, and availability of customer data.

1. Purpose

This Information Security Policy ("Policy") defines the security controls, practices, and responsibilities that protect the confidentiality, integrity, and availability of information processed by Beneficiary.io — including customer estate-planning data, linked financial-account information, and personal information governed by the GDPR, CCPA, and applicable U.S. state laws.

2. Scope

This Policy applies to:

• All Beneficiary.io personnel: founder, employees, contractors, and advisors.
• All systems, applications, and infrastructure operated by Beneficiary.io.
• All customer, employee, and third-party data processed in connection with the Beneficiary.io service.
• All third-party integrations, including Stripe (billing), Plaid (financial account aggregation), BlueNotary (remote online notarization), Firebase / Google (authentication), Anthropic (AI advisor), and Amazon Web Services (infrastructure).

3. Roles and Responsibilities

• Founder & Head of Security — owns the information-security program, approves this Policy, leads incident response, and is the primary contact for security questions and vulnerability disclosures.
• All personnel — comply with this Policy, complete required security training, report suspected incidents promptly, and protect the systems and data they access.
• Third parties — vendors processing customer data on Beneficiary.io's behalf are contractually required to operate equivalent or stronger controls and undergo periodic review.

4. Information Classification

5. Access Control

• Identity — All user access is authenticated via Firebase Authentication. All API access requires a valid Firebase ID token, verified on every request by the FirebaseAuthenticationFilter.
• Multi-factor authentication — SMS-based MFA is available to all customers through Firebase Identity Platform. MFA is enforced on all internal AWS root and IAM user accounts.
• Authorization — Authorization is enforced at the API layer based on user identity, organization membership and role (CONSUMER / MEMBER / ADMIN), and resource ownership.
• Multi-tenant isolation — Every organization-scoped API endpoint validates that the requested resource belongs to the organization resolved from the request's X-Forwarded-Hostname header. Cross-tenant access attempts are rejected with HTTP 403.
• Least privilege — AWS IAM roles are scoped to the minimum permissions required for each service. Production access is restricted to authorized personnel.
• Account lifecycle — User access is reviewed periodically. Departing personnel access is revoked promptly upon role change or separation.

6. Data Protection

6.1 Encryption in transit

• All external traffic uses TLS 1.2 or higher, terminated at AWS CloudFront and the Application Load Balancer.
• HTTP requests are automatically redirected to HTTPS.
• HSTS (HTTP Strict Transport Security) headers instruct browsers to use HTTPS exclusively.

6.2 Encryption at rest

• All DynamoDB tables and S3 buckets are encrypted at rest using AWS-managed KMS keys.
• Highly sensitive customer data (notably Secret Notes intended for delivery to designated heirs) is additionally encrypted with per-resource KMS keys before storage.

6.3 Key and secret management

• All encryption keys are managed by AWS KMS. KMS key access is logged via AWS CloudTrail.
• Third-party API credentials (Stripe, Plaid, BlueNotary, Firebase, Anthropic) are stored exclusively in AWS Secrets Manager and injected into the ECS task environment at runtime.
• Secrets are never committed to source control. Source control is scanned for accidental secret commits.

7. Application Security

• Webhook integrity — All inbound webhooks (Stripe, BlueNotary) require HMAC-SHA256 signature verification with constant-time comparison. A five-minute timestamp tolerance protects against replay attacks. Webhooks with invalid signatures are rejected with HTTP 401.
• Idempotency — Webhook event IDs are tracked to prevent duplicate processing of replayed or retransmitted events.
• Cross-site request forgery — Beneficiary.io's API uses stateless bearer-token authentication; no session cookies are issued for authenticated requests, so CSRF is not an applicable risk surface.
• Input validation — All API inputs are validated server-side. Database interactions use parameterized AWS SDK calls and typed DTOs.
• Dependency management — Third-party dependencies are tracked in pom.xml (server) and package.json (frontend). Published security advisories are monitored; vulnerable versions are patched promptly.

8. Logging and Monitoring

• Audit log — Every state-changing API call produces an AuditEvent capturing the user ID, action, entity type and ID, IP address, user-agent, request ID, and timestamp. Retention follows the customer's plan: Free 90 days, Starter 1 year, Professional 3 years, Enterprise 7 years.
• Application and infrastructure logging — Amazon CloudWatch Logs aggregates application logs across ECS containers. ALB and CloudFront access logs are retained.
• Webhook activity — All inbound and outbound webhook events are logged with their signature-verification status and response codes.
• Authentication anomalies — Excessive failed authentication attempts, unusual geographic patterns, and other anomalies are surfaced via Firebase Authentication's built-in monitoring.

9. Incident Response

• Reporting — Suspected security incidents and vulnerability reports may be submitted by anyone to [email protected]. Disclosure expectations are published at /.well-known/security.txt.
• Triage — The Founder & Head of Security triages reports within one business day, classifies severity, and initiates containment as required.
• Containment, eradication, recovery — Affected systems are isolated; root cause is investigated; corrective controls are deployed; affected data and systems are restored from validated backups where required.
• Notification — Customers, partners, and regulators are notified of incidents involving their data when required by applicable law within the applicable statutory windows.
• Post-incident review — A written post-incident review is produced for any incident classified High or Critical.

10. Vendor and Third-Party Risk Management

• Vendor inventory — Beneficiary.io maintains a record of third-party processors of customer data: Stripe, Plaid, BlueNotary, Firebase / Google, Anthropic, and AWS.
• Selection criteria — Vendors processing customer data are selected based on documented security controls, applicable certifications (SOC 2 Type II, ISO 27001, PCI DSS), and contractual data-protection commitments.
• Periodic review — Vendor controls are reviewed at least annually and upon material changes.

11. Business Continuity and Disaster Recovery

• Resilience — ECS services run across multiple Availability Zones. DynamoDB tables replicate across multiple Availability Zones by design.
• Backups — DynamoDB Point-in-Time Recovery (PITR) is being enabled across all customer-data tables, providing a 35-day continuous backup window. S3 versioning is being enabled for buckets containing customer documents and notarized wills.
• Recovery objectives — Current target RTO ≤ 4 hours; RPO ≤ 1 hour for customer data. Formal RTO/RPO testing is part of the SOC 2 audit preparation roadmap.

12. Physical and Environmental Security

Beneficiary.io operates without dedicated office facilities. Workstation security is addressed by:

• Full-disk encryption required on every personnel device used to access internal systems or customer data.
• Strong, unique passwords or hardware security keys for all business-related accounts.
• Multi-factor authentication required on all systems handling customer data.

Infrastructure runs in Amazon Web Services data centers, which maintain SOC 2 Type II, ISO 27001, PCI DSS, and additional certifications.

13. Personnel Security

• Background screening — As Beneficiary.io expands beyond the founder, employees and contractors with access to customer data will be subject to background screening commensurate with role sensitivity.
• Security-awareness training — All personnel will complete onboarding security training and annual refresher training.
• Confidentiality and IP — Personnel agreements include confidentiality and intellectual-property assignment provisions.
• Acceptable use — Personnel must use Beneficiary.io systems only for authorized business purposes.

14. Privacy and Compliance

• Regulatory commitments — Beneficiary.io operates in alignment with applicable data-protection laws including the GDPR, CCPA / CPRA, and U.S. state-level financial-data and breach-notification statutes.
• Privacy by design — Customer data is collected only as necessary to deliver the service, retained only as long as needed, and deleted upon account termination subject to applicable retention requirements.
• Customer rights — Customers may request access to, correction of, or deletion of their personal data via [email protected].
• SOC 2 — A SOC 2 Type II audit engagement is scheduled to begin upon closing of seed financing, using an automated compliance platform for evidence collection.

15. Policy Governance

• Approval — This Policy is approved by the Founder & CEO and reapproved on each review.
• Review cycle — Reviewed at least annually, and additionally when material changes to systems, vendors, or regulatory requirements occur.
• Distribution — Published at this URL and provided to vendors, partners, and regulators on request.

16. Exceptions

Exceptions to this Policy require documented written approval by the Founder & Head of Security, are time-bound, and require documented compensating controls.

17. Contact

• Security inquiries, vulnerability reports: [email protected]
• Privacy inquiries: [email protected]
• Disclosure expectations: /.well-known/security.txt