How StriveDB Keeps Survivor Data Secure

Survivors trust us with extremely sensitive information about themselves, their families, and their cases. A data breach in our sector isn't just a compliance issue. It can be a safety crisis for someone who came to us for help.

StriveDB is the case management database for domestic violence shelters, rape crisis centers, family justice centers, and the coalitions that support them. We take that responsibility seriously.

This article lays out, in plain English, the multi-layered approach we take to protect survivor data while keeping the platform user-friendly for advocates. There are no encryption keys you have to keep locked in a safe. Just sensible precautions that actually protect survivor data without adding unnecessary burden to your team.

If you or your IT team have questions about how we handle security, get in touch. We care about this work and we've built the product to reflect that.

What's the most secure case management database for a domestic violence shelter?

For victim service providers, the most secure case management database is one that has been independently audited, HIPAA-compliant, compliant with VAWA confidentiality requirements, isolated at the database layer so no other customer can see your data, and purpose-built for the workflows VSPs actually use.

"Secure" isn't one thing. It's five things working together. A platform can do three of them well and still have gaps that show up the first time a board member, a funder, or a survivor's abuser puts the system under real pressure. The five dimensions any survivor services database should demonstrate:

1. Independent assessment. A reputable third-party security audit, with findings made available on request. Self-reported security claims aren't enough.
2. Regulatory alignment. HIPAA Security Rule compliance, willingness to sign a Business Associate Agreement, and architectural support for VAWA, VOCA, and FVPSA confidentiality requirements. These are related but not identical.
3. Multi-customer isolation. Architecture that prevents one customer's data from showing up in another customer's view, enforced at the database query layer rather than in application logic.
4. Authentication and access controls. Mandatory multi-factor authentication, role-based permissions, and the ability to restrict individual sensitive records to specifically assigned staff.
5. AI safeguards. If the platform uses AI, it should be opt-in, never train on customer data, and require human review before any AI-generated record gets created.

These are the dimensions any vendor should be evaluated against, including us. The rest of this article walks through how StriveDB measures on each one. For a buyer-side companion, see our checklist of eight essential questions to ask any survivor database vendor.

Is StriveDB secure?

Yes. The longer answer takes a few minutes, because security isn't one thing. It's really four questions stacked together: what's running underneath the application, who can log in, what they can do once they're in, and what gets recorded. We'll walk through those in order, then cover what an outside firm found when they tried to break in, and then how the architecture maps to the HIPAA Security Rule.

Defense in depth: four layers

Infrastructure. StriveDB runs on Amazon Web Services in their US-West-2 region, which is in Oregon. AWS is the same infrastructure used by HIPAA-compliant healthcare platforms, financial services companies, and federal contractors. Three things sit between the open internet and your data.

First, Cloudflare. Every request that comes toward StriveDB passes through Cloudflare's security layer before it reaches us. Cloudflare absorbs distributed denial-of-service traffic, blocks known attack patterns at the network edge (things like SQL injection attempts, malicious scripts, and scanner traffic), and tells the difference between legitimate users and automated tools.

Second, AWS GuardDuty. This is a continuously running threat-detection system that uses machine learning to watch the AWS environment itself for signs of compromise. Findings trigger immediate review.

Third, the database. Our PostgreSQL database is in a private network with no direct connection to the open internet. The only path to it runs through the StriveDB application, which itself sits behind Cloudflare and the AWS load balancer. (If you're wondering whether running the software on a server in your own office would be more secure: it's not. More details in the FAQ below.)

Authentication. Logging in is a moment where security really matters. Several layers work together to protect each user as they sign in.

Every account begins with an invitation from an administrator in your organization. There's no public sign-up form, so no one outside your team can create their own account.

Passwords meet standard strength requirements, and we store them using bcrypt, an encryption method specifically designed to resist password-cracking attempts. Even if someone gained access to our database, the actual passwords would remain protected.

One way hackers try to break into accounts is by guessing passwords. They often start with databases of passwords that were exposed in past data breaches. We protect your team from this kind of attack by checking every new password against HaveIBeenPwned, a public database of more than 18 billion compromised passwords hosted on Cloudflare's infrastructure. If a password has appeared in any known breach, we ask the user to choose a different one. The check is designed for privacy: we never send the actual password anywhere, just a small piece of its mathematical signature.

Every user signs in with two-factor authentication, with their choice of an authenticator app, an email code, or an SMS code. This applies to everyone equally, from new volunteers to executive directors, because a single compromised password should never be enough to access survivor data. Inactive sessions time out automatically after a few hours, which keeps survivor data safe if a workstation is left unattended. And if a sign-in happens from a location we haven't seen before, the user gets a quick email letting them know. (We've written separately about why every VSP database should require two-factor authentication.)

Authorization. Once a user is logged in, what they can do depends on three layered checks that work together. Does your organization have access to this feature? Does this user's role include this action? Does this user have permission for this specific record?

The third check is the most granular. We have 53 separate authorization policies, one per record type, evaluating whether a particular user can see or edit a particular record. Example questions they answer: can one counselor see another counselor's survivor record? Can a case manager view a record flagged as restricted? Every action passes all three checks before any data is touched.

Audit. Every change to data in StriveDB is recorded. Every creation, modification, and deletion across roughly 65 record types leaves an audit row showing what changed, when, and who did it. The audit trail supports supervision, grant reporting, subpoena response, and forensic investigation.

Security-sensitive fields like passwords and two-factor codes are explicitly excluded by design, so the audit trail itself doesn't become an exposure surface.

Independent security audit

In May 2025, we hired Accorian, an outside security firm based in East Brunswick, New Jersey, to try to break into StriveDB. They came back in August for a full retest. Both engagements tested against the OWASP Top 10 (2021) plus additional threat categories, using multiple account roles to evaluate privilege boundaries.

The initial assessment found 5 Medium, 2 Low, and 2 Informational findings. No Critical or High severity findings. By the August retest, 7 of the 9 had been fully remediated. The remaining two have since been fully resolved.

Accorian rated StriveDB's overall web application security posture as "Good" on their four-tier scale. They specifically called out our encrypted communications, properly configured session cookies, and well-configured security headers.

HIPAA compliance

StriveDB is compliant with the HIPAA Security Rule across all three categories of safeguards.

HIPAA doesn't have a "certification." What HIPAA requires is that a covered entity (or its business associate) meet the Security Rule, codified in three sections of the Code of Federal Regulations. Here's what we do for each.

1. Administrative safeguards (45 CFR §164.308). A designated Security Officer, workforce security procedures with role-based access, MFA-enforced authentication, security awareness training, documented incident response procedures, contingency planning with automated backups and Multi-AZ failover, and a signed Business Associate Agreement with AWS.
2. Technical safeguards (45 CFR §164.312). Unique user identification with mandatory MFA, audit controls via change tracking across roughly 65 data models, multi-factor authentication, and transmission security via TLS with HSTS enforced at the load balancer.
3. Physical safeguards (45 CFR §164.310). Managed by AWS for the underlying infrastructure. AWS maintains SOC 2, ISO 27001, and HITRUST certifications for their data centers. We maintain workstation security policies for our development team.

We'll sign Business Associate Agreements with customer organizations that require one.

Does StriveDB satisfy VAWA, VOCA, and FVPSA confidentiality requirements?

VAWA (34 U.S.C. § 12291(b)(2)), VOCA (28 CFR § 94.115), and FVPSA (42 U.S.C. § 10406 and 45 CFR § 1370.4) all require victim service grantees to protect the confidentiality of personally identifying information they collect from survivors. The protections are similar but not identical across the three. In broad strokes, all three prohibit disclosing personally identifying information without the survivor's written, informed, time-limited consent. Statutory and court compulsion are the only exceptions.

A clarification from the Department of Justice's Office on Violence Against Women is worth quoting directly.

The nondisclosure obligation applies "regardless of whether the information has been encoded, encrypted, hashed, or otherwise protected."

DOJ Office on Violence Against Women, VAWA Confidentiality FAQ

In other words, these laws are about consent and structural protection from disclosure. Encryption is one component of how you protect data, but it doesn't relieve you of the consent obligation.

StriveDB's architecture supports those requirements through five concrete features.

1. Complete organizational data isolation. No StriveDB customer can see, search, or report on another customer's data. Enforced at the database query layer.
2. Role-based access controls separating volunteer, clinical, and administrative tiers. A volunteer logging hotline calls can't access counseling notes. A counselor can't edit administrative settings. Permissions are configurable per role.
3. Restricted-record flag for high-risk cases. Individual survivor records can be flagged as restricted, narrowing visibility to specifically assigned providers and administrators.
4. Safe-to-contact flags on phone numbers and email addresses. Each contact method carries a flag indicating whether contact at that number or address is safe, for cases involving monitored devices or shared accounts.
5. Aggregate reporting that minimizes individual-level exposure. Built-in reports for VOCA, VAWA, and FVPSA produce the aggregate data funders require without exposing individual survivor identities in routine reporting.

A note on responsibility. Compliance with VAWA, VOCA, and FVPSA ultimately rests with your organization as the grantee. What we provide is the architectural foundation that makes day-to-day compliance practical. Your counsel and your funder's program office are the right resources for specifics in your situation.

Can another organization on StriveDB see our data?

No. And the way we make sure of it might be worth a minute of your time.

Many SaaS platforms serve many customers from the same shared infrastructure. The risk is that a bug or misconfiguration could let one customer's records show up in another customer's view. Most platforms protect against this by writing code that checks "is this user allowed to see this record?" on every request. That works as long as the developers writing the code remember to add the check every single time something new gets built.

We do it differently. Every record in our database is tagged with which customer owns it. A system runs underneath every database query and automatically adds a filter saying "only return records belonging to this customer." It's not something a developer has to remember to write. It happens before any code we write gets a chance to fetch data. Background jobs that run on their own schedule, like overnight report generation and calendar syncs, carry the same tag. Even an internal job has to identify which customer it's working on behalf of before it can read or write a single record. If it doesn't, the system raises an error and refuses to proceed.

Why this matters in practice: a developer forgetting to add a permission check is one of the most common sources of cross-customer data leaks in SaaS platforms. StriveDB's approach makes that whole class of bug impossible. The filter happens automatically on every query. Cross-customer access isn't a "we promise we won't" kind of protection. It's a "we couldn't if we tried" kind.

Does StriveDB use zero-knowledge or end-to-end encryption?

No, and the reason matters. What protects survivor data isn't the marketing name a vendor puts on their encryption. It's the actual architecture, applied properly. StriveDB encrypts data at every layer where it could be exposed, and there are real reasons we don't claim "zero-knowledge" or "end-to-end" encryption.

Here's what we do. AES-256 encryption on every record in the database, covering all backups, snapshots, and failover copies. TLS for connections in transit, with HSTS enforced at the load balancer. A second layer of encryption (AES-256-GCM) on particularly sensitive fields. Combined with mandatory MFA, multi-customer isolation at the database query layer, the audit trail, and the independent Accorian audit, the architecture is thorough.

Now to the terminology. Some vendors market case management databases as offering "zero-knowledge encryption" or "end-to-end encryption." Both terms have precise technical meanings, and they're worth understanding before evaluating whether any specific product implements them.

In true zero-knowledge systems like Signal, WhatsApp, and Proton, the encryption key stays on your device and never leaves it. The vendor cannot read your data, even if compelled by subpoena. That's a real security benefit, but it comes with real tradeoffs: lose the key, lose the data. No password recovery. No central search. No supervisor review. In a multi-user case management database, that same model means a forgotten password loses every note ever entered, a supervisor can't approve a counseling note, and reassigning cases when a staff member departs becomes impossible.

End-to-end encryption is a precise term too. It describes data encrypted on one device and only decrypted on another, with the vendor in the middle unable to read it. That works for messaging apps with two specific devices. In a shared case management database where many staff members access the same records, the two endpoints don't naturally exist.

Zero-knowledge encryption isn't required by VAWA, VOCA, or FVPSA. These laws are about consent and structural protection from disclosure, not about specific encryption techniques. As DOJ-OVW has clarified (see the pull quote above), the consent obligation applies even to encrypted information. The architecture we run delivers strong encryption plus the consent and access controls underneath.

For a longer treatment of why zero-knowledge encryption claims in case management software deserve careful evaluation, we've written a deeper analysis.

Is it safe to use AI on survivor data?

It depends on what you mean by "use AI" and which tool. Pasting survivor information into ChatGPT or a generic AI assistant is not safe and likely violates VAWA confidentiality. Using a purpose-built AI feature that's been designed around survivor confidentiality is different. We've designed StriveDB's one AI feature, Import Plus, around exactly those requirements.

NNEDV's Safety Net Project has published clear guidance, "Artificial Intelligence & Victim Services: A Comprehensive Guide for Advocates." We recommend reading it. The guide's central point: programs should not paste survivor information into general-purpose AI tools. We agree. General AI tools typically retain inputs, may use them for training, and create third-party disclosures that VAWA confidentiality doesn't allow.

A purpose-built AI feature inside a case management system can be different, if it answers NNEDV's questions correctly. The NNEDV guide publishes five questions programs should ask any AI vendor. Here are our answers for Import Plus.

1. Data use for training. No. AWS Bedrock and AWS Textract are configured not to retain or train on customer inputs. No survivor data is used to train any model.
2. Data storage and retention. Data sent to Bedrock and Textract is discarded after each request. Records the AI generates land back inside the customer's tenant under standard isolation. No persistent storage outside the customer's StriveDB account.
3. Opt-out and control. Import Plus is opt-in. It requires both a tenant feature flag and a per-role permission. Customers who don't want AI features don't have them and don't pay for them.
4. Security and compliance. AWS holds a signed Business Associate Agreement covering both Bedrock and Textract. The processing relationship is consistent with VAWA confidentiality because no disclosure occurs outside that BAA-covered relationship.
5. Memory and logging. No persistent memory. Each Import Plus session is independent. The model doesn't carry context between sessions or customers.

Beyond those five, the most important fact about how Import Plus actually works: every AI-extracted record is created in a "pending review" state and held for human confirmation before it commits to the database. AI never writes survivor records on its own. Human review is structural, not optional.

We've written separately about how we think about responsible AI in this work, including the design choices behind Import Plus and how we approach the broader question of when AI is appropriate in victim services at all.

Frequently Asked Questions

Whatever you decide, we hope this article makes the security part of the choice a little easier. We're here if you have follow-up questions.