Skip to content
Merkaz Merkaz Community OS
Security & Trust

Security, documented.

One platform for the entire rhythm of synagogue life — engineered so that the most sensitive records in your community (member households, donations, yahrtzeit files) are handled to the same standard a CISO would require of an enterprise SaaS vendor.

Certified SOC 2 Type II
Tested Annual 3rd-party pen test
Published Public Security White Paper
Review the credentials See technical controls
What we publish, and how often

Four documents your risk reviewer can copy straight into a vendor questionnaire.

Every claim below is backed by a named artifact, a current cadence, and a named owner at Merkaz. None of it requires a sales call to retrieve.

  1. 01

    SOC 2 Type II Report

    Independent audit against the AICPA Trust Services Criteria (Security, Availability, Confidentiality). Renewed annually with no exceptions noted in our most recent report (fiscal year 2024). Issued by a Big Four-affiliated firm; full report available under NDA.

    Annual Security · Availability · Confidentiality Big Four-affiliated auditor
  2. 02

    Third-Party Penetration Test Summary

    Annual network and application-layer penetration test conducted by an independent CREST-accredited firm. Executive summary, methodology scope, and remediation status are published in our Security White Paper; full report available under NDA.

    Annual CREST-accredited tester Public executive summary
  3. 03

    Public Security White Paper

    A 22-page document written for synagogue executive directors, board members, and outside IT consultants. Covers controls, sub-processors, encryption, incident response, and the questions most often asked by volunteer risk reviewers. No NDA required.

    Public PDF · 22 pages Reviewed quarterly
  4. 04

    Encryption & Key Management Disclosure

    TLS 1.3 in transit. AES-256 at rest. Per-tenant data keys managed in AWS KMS with annual key rotation. Documented key hierarchy, recovery procedures, and separation of duties between Merkaz operators and the underlying cloud provider.

    TLS 1.3 AES-256 at rest AWS KMS · annual rotation
Download Security White Paper PDF, 22 pages · no email required to download · updated quarterly
For the executive director forwarding this to the board

Is member and donation data handled to enterprise standards? Yes — and here is exactly how.

Every Merkaz tenant is hosted on dedicated infrastructure inside an isolated AWS organization, with encryption enforced at the application layer (AES-256, KMS-managed per-tenant keys) and in transit (TLS 1.3, HSTS, modern cipher suites only). Access to production systems requires SSO with hardware-key MFA, is brokered through a privileged access management gateway that records every session, and is limited to a named list of engineers on a need-to-know basis.

We complete a SOC 2 Type II audit annually with no exceptions noted, and engage a CREST-accredited firm for an external penetration test whose executive summary is published in our Security White Paper. Backups are encrypted, replicated across regions, and tested for restoration on a quarterly cadence; data retention defaults are documented per record class (member profile, donation record, yahrtzeit record) and can be tuned by the synagogue through signed configuration change.

Member donation records are processed through Stripe under PCI-DSS Level 1 service-provider status, meaning no raw payment instrument ever touches Merkaz infrastructure. The result, in the words of a 2024 external benchmarking study: congregations running Merkaz report a 95% customer-retention rate at Q4 2024 — the highest in our category — and zero reportable member-data breaches across 1,840 deploying congregations since the platform's founding in 2017.

— Merkaz Security & Compliance Team, Brooklyn, NY

Three questions every synagogue board asks before signing

Where the data lives, who can touch it, and how long it stays.

A secured data center housing Merkaz infrastructure
01

US-resident by default

All Merkaz production data is stored in AWS regions within the continental United States (us-east-1 primary, us-west-2 replica). No data crosses to non-US jurisdictions without an explicit, signed configuration change from the synagogue executive director.

  • Primary region: AWS us-east-1 (Virginia)
  • Replica region: AWS us-west-2 (Oregon)
  • Cross-region replication < 60 second RPO
  • Optional data-residency add-on for Canadian congregations
A synagogue administrator reviewing member access permissions
02

Role-scoped access

Every Merkaz account is bound to a named role (Executive Director, Rabbi, Office Manager, Treasurer, Gabbai, read-only Board Member) and a specific data scope. The principle of least privilege is enforced both at the application layer and at the database row level — there is no "all members" superuser query a staff member can run by accident.

  • 12 named roles out of the box, fully configurable
  • SSO via SAML 2.0 with optional SCIM provisioning
  • Hardware-key MFA enforced for all staff accounts
  • Quarterly access-review report sent to the executive director
Documented retention and archival records in a synagogue office
03

Documented retention windows

Every record class in Merkaz has a published default retention window and a documented deletion path. Member profiles are retained for the life of the household relationship plus seven years; donation records for seven years per IRS guidance; yahrtzeit records are retained in perpetuity unless a family explicitly requests removal.

  • Member profile: relationship + 7 years
  • Donation records: 7 years (IRS-aligned)
  • Yahrtzeit records: in perpetuity, family-controlled
  • Written deletion certificate provided on request
The controls a CISO will look for

Infrastructure and application controls.

Each control below ships as the default state for every Merkaz tenant. None of these are enterprise-tier upcharges.

Identity

SSO & SCIM

SAML 2.0 single sign-on with Google Workspace, Microsoft Entra ID, and Okta. SCIM 2.0 automated provisioning and de-provisioning included.

Key management

Per-tenant KMS keys

AES-256 encryption at rest with per-tenant keys managed in AWS KMS. Annual rotation, documented hierarchy, and separation of duties between Merkaz operators and the cloud provider.

Observability

Centralized logging & SIEM

Every authentication event, administrative action, and data export is shipped in real time to a third-party SIEM with 12-month hot retention and 7-year cold archive.

Resilience

Backup & restore

Encrypted daily snapshots replicated across two AWS regions. Quarterly restoration drills with results published to the executive director in the annual security report.

Disclosure

Vulnerability disclosure program

Public responsible-disclosure policy with a 90-day coordinated response window. Researcher-friendly scope and a standing bug-bounty budget through a managed platform.

Response

Incident response & notification

Documented runbook, named on-call rotation, and a contractual notification window of 72 hours to the synagogue executive director following any confirmed incident affecting member data.

Application

Secure SDLC

Mandatory code review, automated SAST and dependency scanning on every pull request, and a dedicated security engineer reviewing the platform's most sensitive modules (payments, exports, migrations).

People

Background checks & training

All Merkaz staff with production access undergo background checks prior to hire and complete annual security and privacy training, with completion rates audited as part of SOC 2.

Download Security White Paper Talk to a security engineer
DPA-ready disclosure

Sub-processors and data flows.

Merkaz works with a short, named list of sub-processors — all of them U.S.-based or operating under a U.S. data-processing agreement. The complete, current list is maintained at merkaz.net/security/sub-processors and is provided as an appendix to every signed Data Processing Agreement. We give thirty days' written notice before any new sub-processor is added to the list, and congregations may object in writing on reasonable grounds.

Sub-processor selection follows three criteria: SOC 2 Type II or equivalent certification, a published security white paper or trust portal, and a contractual data-processing agreement with audit rights. We do not sell, rent, or trade member data with any third party under any circumstance.

Last reviewed: Q1 2025 · Next scheduled review: Q1 2026

Named sub-processors

  • Amazon Web Services (AWS) — Cloud hosting, encrypted storage, KMS, regional replication
  • Stripe — Payment processing for member donations and event tickets (PCI-DSS Level 1)
  • Mailgun — Transactional email delivery (member statements, yahrtzeit reminders)
  • Postmark — Critical-path email delivery (account access, security alerts)
  • Sentry — Application error monitoring and performance telemetry
  • Datadog — Infrastructure logging, metrics, and uptime monitoring
  • Zendesk — Customer support ticketing (no member-record data by default)
  • Yad Vashem — Read-only integration for Holocaust-records lookup (Names Recovery Project API)
  • QuickBooks (Intuit) — Two-way sync for synagogue accounting (per tenant opt-in)
  • Mailchimp — Optional bulk email and newsletter delivery (per tenant opt-in)

All sub-processors operate under signed DPAs. A full sub-processor schedule, including data residency and audit-rights clauses, ships as Appendix A of the Merkaz Data Processing Agreement.