Security built into every layer of the platform.
MSOFT handles claim data for risk pools, carriers, TPAs, JPAs, and self-insured employers. Every design choice - from where the data lives to how AI touches a claim - starts with the same question: could a supervisor defend this decision six months from now? Here is what "yes" looks like in practice.
Six practices baked in at the platform level.
Not opt-in modules. Not roadmap items. These are the defaults for every MSOFT deployment from day one.
-
Per-tenant database isolation
Every customer gets a physically separate database. There is no shared "customers" table with row-level tenant guards. A misconfigured query in one tenant cannot leak data into another - the connection literally cannot see the other tenant.
-
Stored-procedure-only data access
No inline SQL in the application layer. Every read and every write goes through a stored procedure. SQL injection is eliminated as a class of vulnerability, and DBAs get one place to audit every access pattern in the system.
-
Full audit logging
Every insert, update, and delete on operational tables is recorded with who, when, what changed, and where it came from. Reserves, payments, diary entries, document uploads - all of it. The audit trail is the source of record for regulatory review.
-
Encrypted secrets
API keys, SMTP credentials, and integration tokens are stored with DPAPI envelope encryption at LocalMachine scope. Secrets decrypt only on the host that owns them - a compromised backup does not yield working credentials.
-
TLS everywhere
Every request forces HTTPS. HSTS is enabled in production. Security headers -
X-Content-Type-Options,X-Frame-Options: SAMEORIGIN, strict-origin-when-cross-origin referrer, restrictivePermissions-Policy- ship on every response. -
Anti-forgery on every form
All mutating requests validate anti-CSRF tokens. Forms cannot be replayed from an attacker's site or embedded in a hostile iframe.
Your database. Your instance. Your choice of infrastructure.
MSOFT is a first-party application, not a multi-tenant SaaS where you have no say in the tenancy model. Every deployment ships as your database, your application instance, and - if you want - your infrastructure.
Data residency is a first-class deployment concern, not an afterthought. Air-gapped on-prem installs work end-to-end. Cloud installs run in the region you specify.
AI you can defend to a supervisor.
Every AI capability in the platform ships with the same three guardrails - because "the model did it" is not an answer we accept, and neither should you.
Human-approval gate on mutations.
Claimsmith drafts diary entries, but nothing writes to a claim until a human reviewer approves. The AI reads freely; every mutation is a human decision.
Explainable predictions.
Every predictive score (severity triage, fraud signals, return-to-work) exposes its top drivers - jurisdiction, body part, litigation status, comparable histories. Agree, disagree, or override with reasons that stay on the claim.
AI actions in the audit trail.
Every prompt, every drafted response, every approval, every override is recorded in the same audit log as manual work. Regulators asking "who did this and why" get the same answer whether the source was AI or a keyboard.
The regulatory posture, baked in.
The platform ships with the compliance surface claims organizations are already required to maintain. These are not add-on modules - they live in the data model.
-
CA WCIS
Continuous FROI/SROI export in the state's required format. Every transmission is logged and reconcilable back to the originating claim event.
-
CMS Section 111
Medicare secondary-payer reporting with mandatory query and claim submission. Response envelopes are parsed back into the claim record.
-
OSHA 300 / 300A / 301
Employer injury logs generated from claim data, ready for annual posting. Lost-day tracking automated from status transitions.
-
CA DWC JET filings Beta
JetFile generates DWC-compliant XML packets, validated against XSD schemas and all 32 DWC business rules end-to-end. OU1/OU2/OU3 EAMS responses parse into typed objects.
-
CA IBR / IMR statutory clocks
Filing-window countdowns run from the trigger date - Second Bill Review for IBR, UR decision for IMR. Deadlines-due dashboard surfaces cases about to lapse.
Permissions live at the query layer, not the UI.
A user who is not allowed to see a claim cannot see it - even if they type the URL by hand, even if they call the API directly. The database is the enforcement point, not the browser.
-
Role-based access at the stored procedure
Every stored procedure takes a session-scoped user context. RBAC rules are evaluated by the database - so bypassing the UI does not bypass access control.
-
Per-application permissions
The suite is modular; so is access. A user can be granted the MSOFT platform but not IntelliReview, or the Mobile portal but not Adhoc reporting. Least-privilege by default.
-
Portal user separation
MSOFTMobile serves two distinct populations - staff and claimants - on the same auth model with different permission grants. Cross-population access is blocked at the stored procedure.
-
Single sign-on
SSO available for staff portal users. Claimant portal supports its own credential store for members without corporate identity.