Effective November 10, 2026 · ArcAngel CRM,
a product of ArcAngel Technical Services, LLC
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. The database and every stored file are also copied to a second
provider, outside our hosting account, where our server can add copies but
never read or delete them.
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, and never their
password, two-factor settings or profile. A session starts only inside a
window of at most 24 hours that the person, or one of your administrators,
approved for that request; responding to a security incident is the one
exception, and is flagged as such in your audit log. It ends when they sign out. The
person being viewed as and your administrators see a banner while it runs,
and an administrator can end it at any time. The one thing we read without one is
what your people send us themselves: feedback through Send feedback,
from anyone with an account, and requests for help through Help &
support, from your staff. Both are encrypted using a separate
administrative key, and your audit log shows each time we open one.
Two-factor authentication is available to every account
at no extra cost, using any standard authenticator app, a hardware security key
such as a YubiKey, or a passkey saved by a phone or computer. A key or passkey
cannot be phished: it signs only for this site’s real address, so a
look-alike page that collects a password gets nothing it can use. We never ask
which make or model of key you have. It is
mandatory for ArcAngel platform staff, who can otherwise
reach every organization, and required of an organization’s
staff unless its administrator turns that off. An administrator can
also require it of the people who use its portals: volunteers, residents,
donors and commercial tenants. 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; a recovery code still works during that lockout.
You are emailed whenever your own sign-in security changes:
a new password, two-factor turned off, a security key or passkey added or
removed, new recovery codes, or a recovery code used to sign in. The email
says what changed and when, and never contains a link or a code, so a change
you didn’t make doesn’t go unnoticed and the email can’t be
imitated to phish you. It comes from ArcAngel, never through an
organization’s own mail server, and gives times in UTC.
A lost second factor is reset by a person who knows you:
an administrator of your organization, after confirming their own second
factor and recording how they checked it was really you. ArcAngel support
does it, with a ticket, only where your organization can’t (its only
administrator, or somebody in more than one organization). Either way you
are signed out everywhere and emailed, the organization’s other
administrators are emailed, and it is in the audit log.
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.
Security testing
Independent security review and penetration testing were completed in
October 2026, including the separation between organizations. No critical or
high-severity issues were found, and every finding was fixed.
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.
An organization can turn two-factor off for its staff.
It is on by default and mandatory for ArcAngel staff, but some organizations
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.
Turning it off is recorded in the organization’s audit log. For the
people who use its portals it is off unless the organization turns it on, so
that somebody can give a gift without an authenticator app.
A security key or passkey is a second factor,
not a replacement for the password. Signing in with a key alone is not offered yet. SMS codes
are not offered either, 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, with a
target Recovery Time Objective of less than 12 hours, 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 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’s designated security contact and all account administrators
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
info@arcangelts.com. 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
info@arcangelts.com.
ArcAngel Technical Services, LLC
