Security and data ownership
Client confidentiality is not a feature. It is the condition of doing the work at all.
Legal aid programs hold the files of people in the worst weeks of their lives, under a duty of confidentiality that does not bend for a vendor’s architecture. Here is how OCM is built and which boundaries you can verify.
Isolation
One organization, one instance, one database
OCM gives each organization its own server, its own database, its own document storage and its own upgrade window. No claim about a competitor's architecture is needed to explain that boundary.
Isolation is also why a bad afternoon stays small. A migration that goes sideways, a report that pins the database, a security incident. Each is bounded to one organization instead of a fleet.
It costs us more to run and we think it is the right trade. It also means you can be handed the whole thing: not an export, the actual running system.
Access control
Who can see what, enforced on the server
Every one of these is checked where the data is read, not hidden in the interface and hoped for.
Security levels
Authorization groups define what a user may read and edit, down to which offices and which reports. Change a user's group and their live sessions are invalidated, so new permissions apply on the next request rather than the next login.
Office scoping
Read and edit rights are granted per office. A multi-office program can let a branch advocate work their own caseload without seeing the rest of the state's clients.
Ethical walls
Wall a specific user off from a specific client or opposing party, and every screen and report honors it. Case detail, contact detail, listings, search and document retrieval each return 403 or filter the row out. Enforced in five places on the server, not once in the interface.
Exports fail closed
Bulk data export is its own permission, and the upgrade that introduced it defaults every group to denied. An administrator opts each group back in deliberately. The other direction would have been easier and worse.
Re-authentication
Sensitive actions such as changing a password or administering another user interrupt the request for a fresh credential check, TOTP included, even inside an already-authenticated session.
Audit log
An append-only record of logins, failures, privilege changes, setting changes and record access, with actor, IP, and a before-and-after JSON blob. The viewer is read-only by design: there is no path in the interface to edit or delete history.
Security in the product
Controls you can inspect, not assurances you have to take on faith
Walk through identity, hardened defaults, automated assurance, ethical walls, contact safety, and responsible AI operations in the running system.
Identity and Access
Real product footage · Captions included
Authentication
Getting in, and staying in
Password handling
bcrypt hashes, with legacy hashes silently upgraded on the next successful login. Failed logins for a username that does not exist spend the same time as ones that do, so login timing cannot be used to enumerate your staff.
Two-factor authentication
Standards-compliant TOTP per user, working with any authenticator app: Google Authenticator, Authy, 1Password, Microsoft Authenticator, or Duo in TOTP mode.
No self-service recovery codes yet; a lost device means an administrator resets MFA.
Single sign-on
OpenID Connect against Microsoft Entra or Google, per deployment. Accounts are never auto-provisioned, and users are matched on the IdP's stable subject identifier rather than email, so reassigning an email address at the IdP cannot quietly log the new person into someone else's account.
One identity provider per deployment.
Session limits
Separate idle and absolute session timeouts, both administrator-configurable, plus a log-out-everywhere kill for a device that walked off.
Forced password change
An administrator-set password is stamped must-change, so it cannot be reused indefinitely. The same applies to the bootstrap account on a fresh install.
Request hardening
CSRF tokens on state-changing requests and a strict content security policy in the current interface, so injected inline script does not run.
Operations
What happens while you are not looking
Monitoring
Uptime and certificate monitoring on every instance, plus host-level intrusion detection and log analysis, with alerts that reach a person rather than a dashboard nobody opens.
Backups
Automated nightly database backups on every hosted instance, verified centrally rather than assumed. A backup nobody has checked is a story, not a backup.
Patching
Releases ship to the demo instance first, then to customer systems through a documented pipeline with a human gate before anything reaches a program's live data. Temporary upgrade-testing environments are not a permanent deployment tier.
Automated review
Every change is scanned for security issues in continuous integration before it can merge, and the findings are triaged rather than filed.
Standing review program
An ongoing internal security review tracks open findings to closure. Items still open are open in writing, not quietly deprioritized.
Admin surfaces are not public
Operational and administrative services are restricted to known networks rather than exposed to the internet and protected by a password.
Questions we get asked
Including the ones with an uncomfortable answer
If a vendor's security page has no line in it that costs them anything, it is marketing.
- Where does our data physically live?
- On a dedicated virtual machine provisioned for your organization in a United States Akamai data center. Akamai publishes PCI DSS 4.0.1 attestation and SOC audit materials in its Trust Center. Those hosting-provider attestations are distinct from our own compliance status. Your database is yours alone.
- Can we get our data out?
- Yes, and not as a favor. Ask and we hand you a dump of your database plus your document storage. The software that reads it is GPL, so nothing about the format is a hostage.
- Do you have SOC 2 or HIPAA attestation?
- OCM does not currently hold its own SOC 2 or HIPAA attestation, and we are evaluating whether to pursue independent attestation. Akamai's data-center and cloud-service attestations cover its infrastructure, not our organization. We can provide source code, security documentation, and a review program whose findings we track and close.
- Who at your company can see our cases?
- Support access is by request and for a purpose, and it lands in your audit log like anyone else's. We do not mine case data, we do not train models on it, and we do not aggregate it across organizations.
- What happens if you get hit by a bus?
- The license is the answer to that question. OCM is GPL, the source is public, and your instance is an ordinary server running ordinary open source software. Any competent shop can pick it up. That is a deliberate design decision, not an accident of licensing.
- Does the AI change any of this?
- Only if you turn it on. OCM supports Gemini on Vertex AI, any OpenAI-compatible endpoint, and Ollama, so inference can run on hardware you or we control end to end. Our preferred managed option is Gemini on Vertex AI: Google Cloud states that it does not use customer data to train or fine-tune models without permission, while its documentation also identifies limited retention scenarios and the steps required for zero data retention. The retrieval layer continues to enforce ethical walls server-side.
Primary references: Akamai Trust Center and Vertex AI data retention documentation.
Send us your security questionnaire
We will answer it in writing, including the questions where the answer is no, and you can check any of it against the source.