Our Trust & Permissions page answers what we can see of yours. This page answers the other question — how the service itself is engineered, governed, and audited, and exactly which credentials we hold and which we don't. No badge on this page is decorative, which is easy to verify: there are no badges.
Each of these is a practice that runs on a schedule or a gate that blocks a release — not an aspiration. Several exist because of something we caught; we would rather tell you that than pretend to have been born perfect.
Monitoring uses read-only authorization granted and revocable at your provider — we never hold passwords. Inside the service, each component gets only the access its job requires, and customer organizations are isolated from one another.
TLS in transit, encryption at rest, and AES‑256‑encrypted offsite backups where we hold the keys — the backup provider stores ciphertext it cannot read. A backup only counts once the encrypted artifact is verified offsite, not when a log line says it ran.
Automated health checks run every five minutes, verified by an independent dead‑man's switch — a monitor that alerts when our monitoring goes quiet, so a silent failure cannot stay silent. Checks assert on real output, not on whether a process claims to be alive.
Every change runs the full automated test suite, and production deployments pass an independent AI security scan for exploitable defects — high-severity findings block the release until fixed and re-verified.
Credentials live in a dedicated secret store with automated guards that block them from ever entering source code. Administrative portals sit behind multi‑factor authentication, geographic access restriction, and forced re‑authentication.
Error tracking runs under a hard scrubbing contract: stack traces and technical context reach our diagnostics provider, personal information does not. The detection stack itself runs malware scanning and daily‑refreshed threat intelligence feeds.
Family Sentinel operates under a formal governance program: a twenty‑document policy library — information security, access control, encryption and key management, logging and monitoring, change management, data retention and destruction, vendor risk, personnel security, business continuity and disaster recovery, and a vulnerability‑management and responsible‑disclosure policy — built to the GLBA Safeguards Rule (a written information security program of the kind U.S. financial institutions are required to maintain). Each document has an owner, a version, and a scheduled review. Alongside the policies sit the operational pieces auditors actually ask about: a live risk register, six written incident‑response playbooks for the 2 a.m. scenarios, and a disaster‑recovery plan whose restore procedure gets tested, not assumed. Any of it is available to customers and prospects on request.
A rule we borrowed from watching other vendors: state your certifications the way you'd want a bank to state its finances. Here is ours, dated and exact.
| Framework | Status today | The plain-English version |
|---|---|---|
| GLBA Safeguards (WISP) |
Program adopted and operating | Our written information security program follows the FTC's Safeguards Rule framework. This is a standard we hold ourselves to, not a certificate anyone issues. |
| SOC 2 Type II | Pending | Our controls are aligned to the SOC 2 Trust Services Criteria; an independent examination by a licensed CPA firm is pending, and the report will be published here when issued. |
If you believe you've found a security issue in anything we run, email security@familysentinel.org with "vulnerability" in the subject line and it reaches a Security Architect directly — expect a fast human response, not an autoresponder. We welcome good‑faith research, we won't respond to it with lawyers, and we'll credit you if you'd like credit.
Our SOC 2 Type II examination is pending — the version where a licensed CPA firm verifies the controls operated over a period of months, not just that they exist on paper. The report will be published here when issued. In the meantime, our security packet answers most of what a SOC 2 report would.
We execute a written incident-response plan with playbooks prepared in advance, and if an incident affects your data or your monitoring, we tell you by email — we don't expect you to discover it from a status page. The structural answer matters more than the procedural one: we keep very little to breach. Safe mail is analyzed and released, never stored; flagged evidence is encrypted and destroyed on a 14‑day timer; and the access token we hold is read‑only and revocable at your provider in one click.
Yes — insurers, boards, and IT reviewers ask regularly. Email security@familysentinel.org and we'll return the completed questionnaire or a security packet (policies, architecture summary, subprocessor list), usually within a few business days.
Security reviews, insurance questionnaires, or one pointed question before you connect anything — ask before you buy, that's the right order. A Security Architect answers every message personally.
Request the security packetCall or text (940) 281-6672 · security@familysentinel.org · What we can see of your mail lives at Trust & Permissions