Security

Your congregation's information is precious — membership details, pastoral notes, prayer requests, family circumstances. You've entrusted it to us, and we take that seriously. Security isn't a box we check; it's a responsibility we carry in every line of code we write and every infrastructure decision we make.

This page explains, in plain language, what we do to protect your data.

How Your Data Is Stored and Transmitted

Encrypted connections (HTTPS / TLS)

Every connection between your browser and Shepherding Tools is encrypted — the same technology your bank uses. This means that even if someone were able to intercept traffic on your network, they would see nothing but scrambled data. We also enforce a setting called HSTS that tells browsers to always use an encrypted connection to our site, preventing any accidental unencrypted access.

Encryption at rest

Your data is stored in a managed database that is encrypted on disk using AES-256 — the same standard used by governments and financial institutions worldwide. "At rest" means encrypted even when the data isn't actively being read or sent anywhere. If the physical hardware were ever stolen, your data would be unreadable without the encryption keys, which are managed separately by our database provider.

Private network architecture

Our application is structured so that only one service — a dedicated "gateway" — is reachable from the public internet. All of the backend services that actually store and process your data run on a private internal network, invisible and inaccessible to the outside world. Attackers have no direct path to your data even if they know our domain name.

Additionally, each backend service cryptographically verifies that every request carries a secret token issued by the gateway. Even if a backend service's internal address were somehow discovered, requests that bypass the gateway are refused at the application level — a second layer of enforcement beyond the network.

Network-layer protection via Cloudflare

All traffic to Shepherding Tools passes through Cloudflare before it reaches our servers. Cloudflare provides network-layer DDoS mitigation, blocks traffic from known malicious IP ranges, and absorbs volumetric attacks before they can affect availability. This is a layer of protection entirely outside our application — it operates at the network level, before any request touches our code.

Protecting Your Account

Password security

We never store your password in plain text. Instead, we store a one-way mathematical transformation of it called a hash (using bcrypt, an algorithm designed specifically for password storage). Even if our database were somehow compromised, attackers could not reverse a bcrypt hash to recover actual passwords. We use a "work factor" that makes each guess computationally expensive, slowing brute-force attacks to a crawl.

Secure session cookies

When you log in, we create a session token stored in a browser cookie. That cookie is marked httpOnly (so JavaScript on the page can't read it — protecting against a class of attacks called XSS), secure (so it's only ever sent over an encrypted connection), and sameSite (so it can't be silently submitted by a malicious third-party website — protecting against CSRF attacks).

If you change your password, any existing sessions on other devices are invalidated at their next page load — they will be required to log in again. The device you used to change the password stays active.

Password reset token safety

When you request a password reset, the link we send you contains a one-time token that is stored in our database in encrypted form — not as the plain token — and is delivered in a way that prevents it from appearing in server logs or browser history. Tokens expire after a short window and are deleted the moment they're used.

Rate limiting and bot protection

Our login and authentication endpoints are rate-limited, meaning automated attempts to guess passwords are blocked after a small number of failures. New account registrations go through a bot-detection challenge to prevent automated sign-ups.

Access Controls

Role-based permissions

Not everyone in your organization sees everything. Permissions are enforced at the API level — not just hidden in the interface — so even a technically sophisticated user can't bypass them. Software-admin access and church-office roles are independent: being listed as an elder or deacon in the system doesn't automatically grant administrative access to the software. Access is also granted app by app: someone who only helps with outreach can be given Connections on its own, without opening the congregation records that the shepherding and prayer apps hold.

Instant revocation

When you remove an administrator's access, it takes effect on their very next request — we don't wait for their session to expire. Administrator rights are verified against the live database on every request rather than read from a cached sign-in. When someone's login access is removed entirely, any session they still have open is signed out as well. Switching a single app off for someone is the one change that isn't instant: if he already has that app open, it closes to him the next time the page or the phone app reloads, not mid-screen.

Church data isolation

Every query our servers run is filtered by your church's unique identifier. It is architecturally impossible for one church's users to read or modify another church's data — the filter is applied at the database layer, not just the interface layer.

How We Handle Sensitive Information

Data never shared for advertising

We do not sell, rent, or share your congregation's data with advertisers or data brokers. Your members' information exists in our system solely to help you shepherd them.

Sensitive fields stripped from API responses

Fields like password hashes, billing identifiers, and integration credentials are stripped from every API response before it leaves our servers — even internal API calls between our own services don't carry them unnecessarily.

Generic error messages

When something goes wrong, what we return to your browser is a simple, generic message. Technical details, database errors, and internal system information are kept in server logs only — they never reach the end user's screen, where they could help an attacker understand our system.

Payments handled by Stripe

We never see or store your payment card details. Billing is handled entirely by Stripe, a payment processor that holds PCI-DSS Level 1 certification — the highest level in the payment card industry. We receive only a token reference, not your actual card information.

Security Headers

Every response from our servers includes a set of security instructions for your browser. In plain language, these tell your browser to:

• Only run scripts we explicitly authorized (preventing injected malicious scripts from executing)
• Always use an encrypted connection, even if a link tries to use plain HTTP
• Never allow the page to be embedded inside another site (preventing "clickjacking" attacks)
• Block access to your camera, microphone, location, and payment hardware unless you explicitly grant it
• Not guess at file types (preventing certain file-based attacks)

Webhook Integrity

We receive automated messages from our payment processor and communications providers. Each of these messages includes a cryptographic signature — a mathematical proof that the message genuinely came from that provider and hasn't been tampered with. We verify every signature before acting on any incoming message.

Two-Factor Authentication on All Platform Accounts

Every account our team uses to manage hosting, source code, the database, email delivery, and billing requires a second factor beyond a password. This means that a stolen password alone cannot be used to access our infrastructure.

Our Ongoing Commitment

Formal written policies

Our security practices are backed by formal written policies: a Security Policy, Incident Response Plan, Change Management Policy, Vendor Risk Management Policy, and a Risk Assessment that identifies, scores, and tracks every known threat category. These documents are reviewed annually and updated after any significant incident or architectural change.

Security built into every change

Every code change goes through a security review before it's committed — this is a defined step in our Change Management Policy, not an informal habit. We check for common vulnerability classes, verify that new routes have the right access controls, and confirm that sensitive data isn't inadvertently exposed in new API endpoints.

Regular comprehensive audits

We conduct full audits as we add features, reviewing the entire codebase against recognized security standards — not just the new code. Multiple comprehensive audits have been completed in 2026, with more planned as the platform grows.

Dependency management

We regularly scan our third-party software dependencies for known vulnerabilities. Our goal is zero high or critical issues in any service at all times. We give extra scrutiny to any library that processes untrusted input.

Audit logging

We maintain a detailed log of security-relevant events: every login (successful or failed), every password change or reset, every time an administrator account is accessed, and every change to who has access — invitations, permission changes, and access removals. These logs are retained for accountability and to support incident investigation if it's ever needed.

Real-time error monitoring

Every one of our services reports errors to a monitoring system the moment they happen. We don't wait for someone to tell us something is broken — we're alerted automatically, with enough detail to investigate and fix problems quickly, often before anyone notices.

Vendor oversight

Every third-party service that handles customer data is evaluated before adoption and reviewed annually. We maintain a formal vendor register documenting each provider's data access, security posture, and contractual commitments. Vendors are never permitted to use your congregation's data for their own purposes.

Privacy Law Compliance

Our Privacy Policy covers our obligations and your rights under applicable data protection law, including:

• GDPR (General Data Protection Regulation) — for users in the European Union
• CCPA/CPRA (California Consumer Privacy Act) — for California residents

We measure our practices against recognized industry security standards and maintain formal written policies covering security, incident response, change management, vendor risk, and threat assessment.

Questions and Security Questionnaires

If you have questions about our security practices, need additional technical documentation, or want to send us your organization's security questionnaire, please reach out at [email protected]. We respond to security inquiries promptly.

To report a potential vulnerability, please use the same address. We commit to acknowledging receipt within 48 hours and to working with researchers in good faith.