Effective September 16, 2026 · ArcAngel CRM,
a product of ArcAngel Technical Services, LLC
Draft — not yet reviewed by counsel.
ArcAngel CRM is in closed alpha and is not accepting public sign-ups. These
documents describe how the Service is actually built and operated today,
but they have not been reviewed by an attorney and should not be relied on
as a final agreement. They will be reviewed before the Service is offered
generally.
An organization deciding whether to put families’ records into this system
deserves specifics rather than adjectives. This page states what protects that
data today, and — just as importantly — what does not yet. The second list is
published for the same reason as the first: a security page that mentions only
strengths is a marketing page.
In place today
Separation between organizations
Every record in the system carries the organization that owns it, and every
read is filtered by the organization of the signed-in user. A request for a
record belonging to another organization is answered as though the record does
not exist — the response does not reveal that it is real but forbidden, which
would itself disclose something. This is enforced in shared code that every
page goes through, not page by page, and it is covered by automated tests that
attempt cross-organization access on each protected view and fail the build if
one succeeds.
Encryption
In transit — HTTPS/TLS for all traffic, with HTTP
Strict Transport Security; TLS between the application and the database; and
a strict-mode certificate between our edge provider and our own servers, so
no leg of the connection is unencrypted.
At rest, field level — names, dates of birth, telephone
numbers, addresses, and the whole of the narrative record — case notes,
incidents, goals, exit assessments — are encrypted individually with
AES-256-GCM before they reach the database. GCM is
authenticated encryption: altered ciphertext fails to decrypt rather than
yielding a plausible wrong value.
A separate key for every organization. Each
organization's data is encrypted with its own key, and each column with a
key derived from that. A record that surfaced under the wrong organization
would fail to decrypt rather than disclose anything, and deleting an
organization's key makes its residual data unreadable — by anyone,
including us.
Documents — every uploaded file is encrypted with the
same algorithm, stored in a private bucket outside the web root under a
random filename that reveals nothing about its contents or owner, and served
only by a permission-checked view. There are no shareable direct links.
Backups — encrypted with a key our hosting provider does
not hold, so a compromise of the hosting account does not yield readable
backups.
Storage layer — the database volumes are additionally
encrypted at rest by the hosting provider.
Access control
Permissions are checked against specific capabilities
(“may export a report”, “may read case notes”) rather than job titles, so
renaming a role cannot silently widen what it can do.
An organization’s administrator decides which roles may read, write, or
not reach each page.
There is no system-level superuser account and no generic database
administration screen.
ArcAngel staff cannot see your records on their own. When
you ask for help, they work in a support session: as one of your users, with
that person's permissions and no more, for up to an hour. The person being
viewed as and your administrators see a banner while it runs, and an
administrator can end it at any time.
Two-factor authentication is available to every account
at no extra cost, using any standard authenticator app. It is
mandatory for ArcAngel platform staff, who can otherwise
reach every organization, and an organization’s administrator can
require it of their own staff. Recovery codes are issued once at setup, each
works a single time, and they are stored hashed rather than in readable
form.
Repeated failed sign-ins lock the account out, and so do repeated wrong
two-factor codes.
Sessions are cookie-based with secure, HTTP-only, same-site cookies, and
every form is protected against cross-site request forgery.
Accountability
Sign-ins, permission changes, and actions on sensitive records — viewing,
editing, exporting, downloading — are written to an audit log. Every support
session by ArcAngel staff is recorded there too, page by page.
How the software is built
Changes reach production only through a reviewed pull request against a
protected branch; the automated test suite and a secret scanner must pass
first.
A commit containing a credential is rejected before it can be pushed.
Dependencies are monitored for known vulnerabilities and patched.
Production deployment refuses to restart the application if database
migrations fail, and verifies the site answers afterwards.
Hosting
United States (New York City region). The application server accepts web
traffic only from our edge provider’s network and administrative access only
from a named address, over key-based SSH with password authentication
disabled. The database is reachable only on a private network. Security
updates are applied automatically.
Not yet in place
These are known gaps, listed with what is being done about them. Each is
tracked in our engineering roadmap.
Staff names are not encrypted. The names of an
organization’s own employees, and the addresses they sign in with, are
stored in the clear — a sign-in address has to be readable to be signed in
with, and it usually contains the name anyway. Records about the people an
organization serves are encrypted; records about its staff are
not.
Two-factor authentication is not required of every organization
by default. It is available to everyone and mandatory for ArcAngel
staff, but whether to require it of their own people is an organization’s
decision. Some run on a shared device at a front desk, where forcing it
produces shared logins — which is worse, because it destroys the audit
trail as well.
Only authenticator apps are supported, not hardware
security keys or passkeys. Those are stronger and are planned; SMS codes are
not, and will not be — they are defeated by a SIM swap.
Recovery from a serious failure is a restore, not a failover.
The Service runs on one server in one region, with encrypted backups held
elsewhere and a restore rehearsed every quarter against real backup files. A
failure that needs that restore is measured in hours, not seconds, and we
would rather say so than imply otherwise.
Confidential-program mode is designed and not yet built.
Suppressing identifying details from exports, reports and printed lists for
a domestic-violence or VAWA program is specified and will be built for the
first organization that needs it — before that organization puts such a
program into the Service, not after.
No independent security audit or penetration test has
been performed. The Service is in closed alpha; an external review is
planned before general availability.
No SOC 2 report, HIPAA Business Associate Agreement, or 42 CFR
Part 2 agreement. See Section 4 of the
Privacy Policy for what that means
for the data you may place in the Service.
If something goes wrong
If we confirm a breach affecting an organization’s data, we will notify that
organization without undue delay and within 72 hours, telling
them what we know, what we are doing, and what they may need to do. We will
not wait for a complete picture before making the first notification.
For an interruption rather than a breach — the Service being unreachable or
something in it not working — what we know is published at
status.arcangelcrm.com, which is hosted away from the
servers that run the Service so that it still answers when they do not.
Administrators at each organization are emailed directly for anything expected
to last more than thirty minutes, and before planned maintenance. Those notices
describe the service and never name an organization, a family or a person.
Reporting a vulnerability
If you believe you have found a security problem, please tell us at
[email protected]. We will
acknowledge within two business days and keep you informed. We will not pursue
legal action against anyone who reports a genuine issue in good faith, gives
us reasonable time to fix it before disclosing it publicly, and does not
access, modify, or retain data belonging to anyone else in the process.
Please do not test against live organizations’ data, run automated scanners
against the Service, or attempt denial-of-service. Ask us and we will arrange
an environment.
Questions about this document? Contact
[email protected].
ArcAngel Technical Services, LLC
