Donor records, contribution histories, and contact information are some of the most sensitive data your organization handles. FundraiserMax is built so that data is protected by default at every layer, with controls that meet the expectations of auditors, treasurers, and the donors you serve.
Every byte of customer data is encrypted in transit and at rest. Sensitive identity and payment fields receive additional protection so a single misconfiguration does not expose donor records.
All connections to FundraiserMax use HTTPS with TLS 1.2 or TLS 1.3. Older protocols (TLS 1.0, TLS 1.1, SSLv3) are disabled. Strict Transport Security (HSTS) is enforced so browsers refuse to downgrade. The application load balancer terminates TLS with certificates issued and rotated by AWS Certificate Manager.
Customer databases and backups are encrypted with AES-256 keys managed by AWS KMS. Object storage for uploads, exports, and generated assets uses server-side encryption with bucket-level public-access blocks. Encryption keys rotate automatically; no operator ever holds an unencrypted snapshot.
Donor identifiers including SSN-style fields, government IDs, and personal notes are stored with column-level encryption on top of the at-rest layer. API responses redact these fields for non-privileged roles. Card numbers and bank account numbers never touch our servers; they go directly to Stripe.
Each organization is a logically isolated tenant with its own ownership scope on every record. Authorization is enforced server-side on every API request, and cross-tenant access is blocked at the data layer rather than only the UI. We do not share databases across customer cohorts.
FundraiserMax processes online donations through Stripe, a PCI DSS Level 1 service provider. Card data is collected in Stripe-hosted elements rendered inside your donation pages, which keeps the cardholder data environment off our servers entirely.
We hold ourselves to the compliance bar of the customers we serve: political committees subject to FEC and state reporting, 501(c) nonprofits handling charitable disclosures, and advocacy organizations operating across state lines.
Our internal control framework is mapped to the AICPA Trust Services Criteria for Security, Availability, and Confidentiality. Controls are evidenced continuously through change management records, access reviews, and automated configuration checks. SOC 2 reports are available under NDA for customers on annual plans.
Stripe is PCI DSS Level 1 certified. Our integration uses Stripe Elements and Setup Intents so the cardholder data environment is descoped from FundraiserMax. We complete our annual SAQ and provide an Attestation of Compliance to customers who ask.
We act as a data processor for customer data. We honor Data Subject Access Requests, deletion requests, and portability requests through built-in tooling. A Data Processing Addendum (DPA) is available on request and is pre-signed for customers on annual plans.
California residents have rights to access, delete, and opt out of the sharing of their personal information. FundraiserMax provides per-contact consent tracking, suppression flags, and exportable activity histories so your team can fulfill verifiable consumer requests within statutory timelines.
Outbound email, SMS, and dialer features include consent capture, opt-out honoring, suppression-list enforcement, and quiet-hour windows by recipient time zone. Audit trails are retained so committees and nonprofits can prove good-faith compliance with telephone and electronic messaging rules.
Contribution limits, aggregate tracking per election cycle, occupation and employer collection, and itemization thresholds are enforced at the data layer. Reports map directly to FEC Form 3, Form 3X, and common state filing schemas so finance teams ship without spreadsheet glue.
FundraiserMax runs on Amazon Web Services in the United States. Public surfaces terminate at a managed load balancer; application and database tiers run inside a private VPC with no inbound internet routes.
A Virtual Private Cloud isolates the application and database. Public subnets host only the load balancer; the application servers and PostgreSQL run in private subnets with egress through a NAT gateway. Security groups deny all traffic by default and allow only the minimum ports required between tiers.
AWS WAF rate-limits abusive traffic, blocks common injection patterns, and rejects requests from sanctioned regions. Bot management strips obviously forged crawler user agents. CloudFront caches static assets across global points of presence to reduce origin load and improve user experience.
Application servers run as a horizontally autoscaled fleet across multiple availability zones. The PostgreSQL database uses Multi-AZ deployment with automated failover. There is no single host whose failure causes downtime, and routine deploys are zero-impact rolling updates.
Application containers are built from minimal base images, scanned for vulnerabilities on every build, and signed before deploy. Operating system patches are applied automatically through the AWS-managed control plane. No long-lived SSH keys exist for production hosts; operators use short-lived session credentials through identity-federated access.
Most data breaches start with stolen credentials. We treat authentication and authorization as a single end-to-end system, not a checkbox.
Strong tooling fails without disciplined operations. The same controls that get FundraiserMax through audits are also what we run on day-to-day.
Third-party penetration tests are commissioned annually and after any major architecture change. Findings are tracked to closure with severity-based SLAs; redacted summary letters are available to customers under NDA.
Dependency manifests are scanned on every commit. Critical CVEs trigger an automated upgrade pull request. We track mean time to patch as a primary engineering metric and run weekly vulnerability review meetings.
Application, infrastructure, and business metrics are observed continuously. On-call engineers receive paging within minutes of anomalies in error rates, latency, payment success ratios, or login behavior. Synthetic checks from multiple regions validate uptime independently.
Encrypted database snapshots run every five minutes with point-in-time recovery for at least 35 days. Object storage is versioned and replicated. We test restores quarterly against production data volumes so RPO and RTO targets are real, not theoretical.
Every production change is code-reviewed, automatically tested, and deployed through a versioned pipeline with audit-logged approvals. Emergency changes follow a documented break-glass procedure and trigger post-incident review.
Staff laptops are managed with full-disk encryption, automatic patching, and endpoint detection. Background checks are run for new hires. Annual security training covers phishing, secure development, and data handling.
Donors and supporters have privacy rights even when they are not the contracting party. FundraiserMax gives your team the tools to honor those rights without custom engineering.
When something does go wrong, customers need clear communication, fast containment, and an honest post-mortem.
Software-as-a-service security is a partnership. FundraiserMax secures the platform; customers control account-level practices.
We welcome responsible disclosure from security researchers. Please email security@fundraisermax.com with a description of the issue, steps to reproduce, and any proof-of-concept material. We respond within one business day, do not pursue legal action against good-faith researchers, and credit reporters on request.
For compliance documentation requests (SOC 2 report, DPA, AOC, sub-processor list, penetration test summary), email security@fundraisermax.com from a customer account contact.