Security

    Security built for the data our customers trust us with.

    Mavenly handles the operational records of nonprofits and the application data of foundations. This page describes how we protect that data — what's live today, what's in flight, and how to escalate to procurement-grade documentation.

    Last updated
    May 1, 2026
    Version
    1.0
    Stage
    Pre-launch

    Pre-Launch Posture — Honest About the Stage. Mavenly is pre-launch. The controls described below are operationally implemented; the formal certifications (SOC 2 Type II, ISO 27001, HIPAA) are in flight against the timelines noted in Section 04. Customers who require completed certifications today should reach out to security@mavenly.ai — we'll share our current readiness materials under NDA and discuss the procurement path for your specific timeline.

    At a glance

    Four pillars of Mavenly's security posture.

    The substance is in the sections below. The summary lives here.

    Encryption everywhere.

    TLS 1.2+ in transit, AES-256 at rest, customer-managed keys for enterprise.

    Access least-privilege.

    RBAC, MFA on paid tiers, SSO on Operator+, quarterly access reviews.

    AI data protection.

    Zero data retention with model providers. No training on Customer Data, ever.

    Incident response.

    72-hour breach notification commitment. Documented escalation procedures.

    Section 01

    Encryption.

    All data in motion and at rest is encrypted using current industry-standard algorithms. The specific controls below describe what's deployed today and how customers can verify the implementation.

    Data in transit
    All traffic between customer browsers and Mavenly's services uses TLS 1.2 or higher with modern cipher suites. TLS 1.0 and 1.1 are explicitly disabled. HSTS is enforced.
    live
    Data at rest
    Customer Data is encrypted at rest using AES-256, the standard FIPS 140-2 approved cipher. Encryption is provided through our cloud infrastructure provider's managed encryption services.
    live
    Backup encryption
    All backup data is encrypted at rest using AES-256 and stored in geographically separated regions. Backup keys are managed independently of production keys.
    live
    Customer-managed keys
    Institution-tier and Foundation Edition customers can opt into customer-managed encryption keys (CMK) via AWS KMS, with key rotation under customer control.
    Q3 2026
    Key rotation
    Production encryption keys are rotated annually as a baseline. Compromise-suspicious rotations occur immediately under our incident response procedures.
    live
    Independent verification

    Customers can verify TLS configuration via SSL Labs (we maintain an A+ rating), and our certificate transparency entries are publicly auditable. Production certificates are issued by Let's Encrypt with automated rotation.

    Section 02

    Access Controls.

    2.1 Customer-side access

    Within the Mavenly platform, customers control who has access to what data through role-based access controls. Roles are assignable per Authorized User and govern the entire experience.

    • Multi-factor authentication is required for all paid-tier accounts. Customers can enforce MFA-only access at the organization level. TOTP and WebAuthn (security keys, biometric) are supported.
    • Single sign-on via Google and Microsoft is available on Operator tier and Foundation Edition. SAML SSO and SCIM provisioning are available on Institution tier and Foundation enterprise plans.
    • Role-based permissions support standard roles (Owner, Admin, Editor, Viewer) and custom roles for Institution and Foundation customers.
    • Session management includes configurable session lifetimes, concurrent-session limits, and forced logout on credential change.

    2.2 Mavenly-side access

    Internal access to production systems and Customer Data follows least-privilege principles. The specific controls:

    • Production access is restricted to a small engineering team designated by role, not by default. Most Mavenly employees have zero access to production systems.
    • Every production action is logged. Logs are tamper-evident, retained for at least 12 months, and reviewable by customers under NDA for their own data on request.
    • Quarterly access reviews are conducted by the security lead. Departed employees lose access immediately; role changes trigger access recertification within 7 days.
    • Customer Data access by Mavenly staff requires a documented support or incident-response justification. Access without justification is a terminable policy violation.
    • Background checks are conducted for all staff with access to production systems, in compliance with applicable employment law.
    Mavenly's commitment

    Mavenly staff do not browse Customer Data. Access to specific customer records requires a documented justification (support ticket, incident response, customer-authorized investigation), is logged, and is reviewed periodically. Customers can request the audit log of staff access to their data at any time.

    Section 03

    Infrastructure.

    Mavenly is hosted on Amazon Web Services (US-East-1 primary, with disaster-recovery capability in US-West-2). Infrastructure follows AWS Well-Architected Framework patterns with defense-in-depth at every layer.

    Cloud provider
    Amazon Web Services. AWS holds SOC 2, ISO 27001, FedRAMP, HIPAA, and PCI DSS attestations. Mavenly inherits these foundational controls under the AWS shared responsibility model.
    live
    Network isolation
    Production runs in dedicated VPCs with private subnets. Public access is restricted to load balancers; databases and internal services are not internet-accessible.
    live
    Web application firewall
    AWS WAF deployed at the edge with rule sets for OWASP Top 10, geographic blocking for sanctioned regions, and rate-limiting against credential stuffing.
    live
    DDoS protection
    AWS Shield Standard is deployed by default. AWS Shield Advanced is targeted for general availability launch.
    GA launch
    Segregated environments
    Production, staging, and development run in separate AWS accounts with no shared credentials. Customer Data never enters non-production environments.
    live
    Disaster recovery
    Cross-region replication for Customer Data with RPO of 15 minutes and RTO of 4 hours. DR procedures tested quarterly.
    live
    Section 04

    Certifications & Attestations.

    Mavenly is pre-launch. The certifications below describe what's targeted, what's in flight, and what's planned. Customers requiring completed attestations today should contact security@mavenly.ai to discuss their specific procurement timeline.

    In flight

    SOC 2 Type II

    The audit-ready operational baseline. Type I attestation targeted within 6 months of launch; Type II observation period (12 months) begins immediately after.

    Type II report: ~18 months post-launch

    Planned

    ISO 27001

    For customers with international procurement requirements where SOC 2 isn't sufficient. Readiness assessment scheduled after Type II.

    Target: 2028

    Planned

    HIPAA Readiness

    For Foundation Edition customers funding healthcare-related programs. We can sign a BAA on Institution and Foundation tiers; formal readiness assessment is scheduled.

    BAA available · readiness 2027

    Live (inherited)

    Cloud Provider Attestations

    AWS holds SOC 2 Type II, ISO 27001, FedRAMP Moderate, and PCI DSS. Mavenly inherits foundational controls under shared responsibility.

    Reports available under NDA

    For customers who need certifications today

    If your procurement requires a completed SOC 2 Type II report before signing, contact security@mavenly.ai. We can share our current readiness materials, AWS's inherited attestations, and the specific controls we have operationally implemented under NDA. For customers whose timeline aligns, we can schedule pilots that bridge to the Type II report's general availability.

    Section 05

    AI Safeguards.

    Mavenly's AI-native architecture introduces security considerations beyond traditional SaaS. The controls below describe how we protect Customer Data when it flows through AI inference, and how we ensure no customer's data can leak into another customer's experience.

    Mavenly's AI commitment

    We do not use Customer Data to train Mavenly's AI models or any third-party AI models for general use, and we will not, ever, without the customer's separate written consent. This is the same commitment in our Privacy Policy Section 4 and our Terms of Service Section 5.2.

    5.1 AI model provider configuration

    Mavenly uses Anthropic's Claude API for AI inference (Compose, Discover ranking, Reporter synthesis, Evaluation analysis). The configuration:

    • Zero data retention endpoints. Mavenly uses Anthropic's API endpoints configured for zero data retention. Customer prompts and AI responses are not stored by the model provider beyond the brief moment required to generate output.
    • Contractually bound non-training. Our agreement with Anthropic prohibits use of Customer prompts or outputs for general model training, fine-tuning, or improvement of any model that any other customer would use.
    • No cross-customer leakage. Each customer's Organization Memory layer is logically isolated. AI inference for Customer A never receives context from Customer B.

    5.2 Prompt injection defenses

    Customer Data submitted to the platform may contain content designed to manipulate AI output. Mavenly's defenses:

    • Input/instruction separation. System prompts and user-provided content are passed through separate channels in AI calls. Customer Data is never interpreted as instructions by default.
    • Output validation. AI output is validated against expected formats before being persisted or displayed. Outputs that fail validation are flagged and reviewed.
    • Source attribution. Every claim in AI Output is traceable to its source in the customer's input. Hallucinations and fabricated citations are caught at the validation layer.

    5.3 AI-specific access logging

    Every AI inference request is logged with the requesting user, the customer organization, the input source, and the output destination. Logs are tamper-evident and retained for 12 months. Customers can request the AI access log for their organization at any time.

    5.4 Custom fine-tuning (Institution & Foundation tiers)

    Institution and Foundation customers can opt into custom fine-tuning that trains a private model on their corpus. The architecture:

    • The fine-tuned model is owned by the customer and is private to their organization.
    • The fine-tuning data never leaves the customer's logical environment within Mavenly.
    • The fine-tuned model is never used to train Mavenly's general models or any other customer's experience.
    • On termination, the fine-tuned model and all associated training data are deleted within 30 days.
    Section 06

    Vulnerability Management.

    Software security is a continuous process, not a checklist. Mavenly's vulnerability management program covers the full lifecycle from secure development through ongoing testing and disclosure.

    6.1 Secure development lifecycle

    • Code review. All code changes require peer review before merge. Security-sensitive changes (authentication, authorization, encryption, AI prompt construction) require review by a designated security reviewer.
    • Static analysis. Automated SAST scanning runs on every pull request. High and critical findings block merge until resolved or risk-accepted with documentation.
    • Dependency scanning. Software composition analysis (SCA) runs continuously against our dependency graph. Critical CVEs trigger automated alerts; patches are deployed within the SLA in Section 6.3.
    • Secret scanning. Pre-commit hooks and post-push scanning catch credentials, API keys, and certificates before they reach the repository. Discovered secrets are revoked immediately.

    6.2 Penetration testing

    • Annual third-party penetration testing by a qualified firm. The first formal pentest is scheduled for 60 days post-launch; reports will be available to enterprise customers under NDA.
    • Continuous automated DAST scanning of production endpoints.
    • Internal red-team exercises are scheduled semi-annually starting Year 2.

    6.3 Patching SLAs

    Critical (CVSS 9.0+)
    Patch deployed within 24 hours of confirmed exploit availability or vendor patch release, whichever is sooner.
    SLA
    High (CVSS 7.0–8.9)
    Patch deployed within 7 days of vendor patch release.
    SLA
    Medium (CVSS 4.0–6.9)
    Patch deployed within 30 days of vendor patch release.
    SLA
    Low (CVSS < 4.0)
    Patched in the next regular release cycle.
    SLA

    6.4 Coordinated disclosure

    Mavenly welcomes responsible vulnerability disclosure from security researchers. To report a vulnerability:

    • Email security@mavenly.ai with details. PGP key available on request.
    • We acknowledge receipt within 2 business days.
    • We commit to remediating critical findings within 30 days; high findings within 60 days.
    • Researchers acting in good faith under our disclosure terms are protected from legal action.

    A formal bug bounty program is targeted for Year 2. Until then, researchers receive recognition on our security acknowledgments page (forthcoming) and, at our discretion, monetary rewards for material findings.

    Section 07

    Incident Response.

    No security program eliminates risk entirely. The measure of a security program is what happens when something goes wrong. Mavenly's incident response procedures define the actions, timelines, and notifications customers can expect.

    Notification commitment

    In the event of a confirmed personal-data breach, Mavenly will notify affected customers without undue delay and in any event within 72 hours of becoming aware of the breach where required by applicable law (e.g., GDPR Article 33). For other security incidents that materially affect a customer's data or service, notification follows the timeline below.

    7.1 Incident response timeline

    T+0
    Detection & escalation
    Alert triggered (automated monitoring, customer report, or internal observation). On-call engineer paged. Severity assessed within 15 minutes.
    T+1hr
    Containment
    Immediate steps taken to limit blast radius — credential rotation, access revocation, traffic isolation, or service degradation as appropriate. Incident commander assigned.
    T+4hr
    Initial assessment
    Scope of impact determined. Affected systems, data, and customers identified. Status page updated for customer-affecting incidents.
    T+24hr
    Remediation in progress
    Active resolution underway. Customer notification drafted for review by counsel and security leadership.
    T+72hr
    Customer notification
    For confirmed data breaches: affected customers notified with description of incident, data categories affected, individuals affected (estimated), steps taken, and recommended customer actions. Regulatory notifications as required.
    T+30d
    Post-incident review
    Root-cause analysis completed. Process and technical changes implemented. Public post-mortem published for incidents with broad customer impact (with customer-specific details redacted).

    7.2 Status page

    Mavenly maintains a public status page at status.mavenly.ai showing the current operational status of all services, planned maintenance windows, and historical incidents. Customers can subscribe to email or Slack notifications for status changes.

    7.3 Incident severity tiers

    • Severity 1: Confirmed data breach, complete service outage, or critical security vulnerability under active exploitation. Pages on-call immediately. Customer notification within 72 hours.
    • Severity 2: Significant service degradation affecting multiple customers, or security incident with potential but unconfirmed data exposure. Pages on-call. Status page updated within 1 hour.
    • Severity 3: Limited service impact (single feature, single customer), or security finding without confirmed exposure. Tracked through normal incident workflow.
    Section 08

    Sub-processors.

    Mavenly engages third-party service providers to operate the platform. Each sub-processor is bound by a written agreement that limits their use of Customer Data to the purpose of providing services to Mavenly, requires industry-standard protections, and supports Mavenly's commitments under our Privacy Policy.

    The current sub-processor list is published at mavenly.ai/sub-processors with email notification available for changes. Customers receive at least 30 days' advance notice of new sub-processors with the right to object before the sub-processor handles their data.

    Initial sub-processor stack

    The pre-launch sub-processor stack: AWS (cloud infrastructure), Anthropic (AI inference, zero data retention), Stripe (payment processing), Postmark (transactional email), Plain (customer support), PostHog (self-hosted product analytics). Full details, data locations, and DPA links at mavenly.ai/sub-processors.

    8.1 Sub-processor selection criteria

    Sub-processors are selected against documented criteria including:

    • Independent security attestations (SOC 2, ISO 27001, or equivalent)
    • Executable Data Processing Addendum with Standard Contractual Clauses for EU/UK transfers
    • Demonstrated capacity for breach notification within compatible timelines
    • Operational maturity sufficient to support our customer commitments

    8.2 Sub-processor changes

    When Mavenly engages a new sub-processor, customers are notified by email at least 30 days in advance. Customers who object to a new sub-processor may terminate the affected portion of their service with a pro-rata refund of unused fees, as described in our Terms of Service.

    Section 09

    Personnel & Operations.

    9.1 Hiring & background checks

    All Mavenly employees and contractors who will have access to production systems undergo background checks consistent with applicable employment law before access is granted. Checks include:

    • Identity verification
    • Employment history verification
    • Criminal background check (where legally permissible)
    • Reference checks

    9.2 Security training

    All employees and contractors complete security awareness training at onboarding and annually thereafter. Training covers:

    • Phishing and social engineering recognition
    • Credential and key management
    • Customer Data handling protocols
    • Incident reporting procedures
    • AI-specific risks (prompt injection, data leakage, model misuse)

    Engineering staff complete additional secure-development training annually. Staff with production access complete role-specific training before access is granted.

    9.3 Endpoint security

    • All employee devices are enrolled in mobile device management (MDM) with disk encryption enforced.
    • Endpoint detection and response (EDR) software deployed on all production-facing devices.
    • Remote-wipe capability for lost or stolen devices.
    • Strong password policy with required password manager use.
    • MFA required on all accounts with access to production systems or Customer Data.

    9.4 Offboarding

    When employees or contractors leave Mavenly:

    • All access to production systems and Customer Data is revoked within 1 hour of separation.
    • SSO sessions are terminated immediately.
    • Hardware is collected and wiped within 7 days.
    • Access logs are reviewed for any post-notification anomalies.

    9.5 Vendor management

    Vendors and contractors with access to production systems or Customer Data are subject to the same security requirements as employees. Contracts include confidentiality, data protection, security controls, and right-to-audit clauses.

    Section 10

    Customer Responsibilities.

    Security is shared. Mavenly's controls protect the platform and the Customer Data within it; customers retain responsibility for the configuration and use of their own accounts. The shared responsibility model:

    Account credentials
    Customer-managed. Strong passwords, MFA enrollment, and secure storage of credentials are the customer's responsibility.
    Customer
    Authorized User management
    Customer-managed. Customers control who has access, what role they have, and when access should be revoked.
    Customer
    SSO configuration
    Customer-configured. Customers on Operator+ tiers configure their SSO provider; Mavenly provides the integration.
    Customer
    Data classification
    Customer-managed. Customers determine what data they upload to Mavenly. Mavenly processes Customer Data per the customer's instructions.
    Customer
    Platform infrastructure
    Mavenly-managed. Network security, encryption, availability, and the controls described in Sections 1–9.
    Mavenly
    AI inference security
    Mavenly-managed. Zero-data-retention configuration, no-training commitment, prompt-injection defenses.
    Mavenly

    10.1 Recommended customer practices

    To get the most from Mavenly's security posture, we recommend customers:

    • Enroll all Authorized Users in MFA at account setup, even on tiers where it's not required.
    • Configure SSO on Operator+ tiers to centralize authentication.
    • Use role-based access deliberately — give Editor or Viewer roles where Admin isn't needed.
    • Review Authorized Users quarterly and remove access for departed staff.
    • Report suspected security incidents immediately to security@mavenly.ai.
    • Don't paste sensitive data the platform isn't designed to handle (e.g., payment cards, SSNs unrelated to grant administration).
    Section 11

    Contact & Documentation Requests.

    For all security-related matters, the routing depends on the type of inquiry. Use the right channel for the fastest response.

    For security incidents & vulnerability disclosure

    Email: security@mavenly.ai

    For reporting suspected security incidents affecting your account, vulnerability disclosures from researchers, or coordinated security communications. PGP key available on request. We acknowledge receipt within 2 business days.

    For procurement & security questionnaires

    Email: enterprise@mavenly.ai

    For SIG Lite, CAIQ, custom security questionnaires, DPA execution, BAA requests (Institution and Foundation tiers), and coordinated procurement reviews. We aim to return completed questionnaires within 5 business days for standard frameworks.

    For NDA-protected documentation

    Available under mutual NDA: AWS attestations, our current SOC 2 readiness materials, internal security policies, penetration test results (post-launch), and detailed sub-processor agreements. Email enterprise@mavenly.ai to begin the NDA process.

    11.1 What to include in your request

    To help us route your inquiry quickly:

    • Your organization name and procurement timeline
    • The specific framework or document you need (SOC 2, SIG, CAIQ, custom questionnaire, DPA, BAA)
    • Whether the request is for evaluation or for an active customer relationship
    • Any specific deadlines

    11.2 Corporate address

    Mavenly, Inc.
    Attn: Security
    777 Brickell Avenue, Suite 500
    Miami, Florida 33131 · United States

    11.3 Page version & updates

    This page describes Mavenly's security posture as of May 1, 2026. We update it as the program evolves — new certifications, new controls, new sub-processors. Material changes are noted in the version history at the top of the page. Customers can subscribe to security update notifications by emailing security@mavenly.ai with "Subscribe to security updates" in the subject line.