Why a supplementary-insurance system shouldn't live inside your main CMS
It's tempting to add "one more module" to whatever platform already runs the public website — a form here, a table there, done. For staff insurance data, that convenience comes with a cost nobody notices until an audit or an incident asks the obvious question: who else can reach this database? FanCover runs as its own isolated service — dedicated MongoDB, internal-only nginx routing — precisely so the answer stays short.
What isolation actually buys, concretely
- A breach in the public CMS doesn't reach insurance records. Separate database, separate credentials, separate blast radius — a compromised marketing page can't pivot into an employee's coverage details.
- Internal-only routing. The service isn't reachable directly from the internet the way a public showcase page is; nginx only exposes what the login flow needs.
- Audits get a one-sentence answer. "What touches employee health data" is a short list, not an inventory of every module bolted onto a shared CMS over the years.
Login through an identity you didn't have to build
Sign-in goes through Iran's national "Dawlat-e Man" identity provider rather than a FanCover-specific username and password. For sensitive HR data, that's not a convenience feature — it means access is tied to a verified national identity with its own audit trail, and there's no separate password for someone to phish, reuse, or leave in a spreadsheet.
The pattern generalizes past insurance
Dependents, coverage history, claims status — none of it needs to sit in the same trust boundary as a public website's content management system. The right default for any staff-facing system handling data an organization would rather not explain in a breach notification is its own service, its own database, and login through an identity the organization already trusts — not a new module in whatever's already running.
