Skip to main content

Security and privacy

Reporting a vulnerability​

Report suspected vulnerabilities privately to security@helpifyr.com. Do not include customer, partner, health, claim, credential, or other restricted data. The public issue tracker is not a vulnerability intake channel.

A Product Security Incident Response Team (PSIRT) owns triage, coordinated disclosure, patch decisions, release provenance, and regulatory reporting assessment. Supported-version and response targets are to be published before the first public production release. No telemetry or support upload is enabled by default. The project's security policy is the binding text.

Supply-chain controls in the project​

  • Security releases require dependency review, an SBOM, signed release provenance, upgrade and restore verification, and a documented vulnerability decision.
  • Dependencies are scanned in CI against the committed CycloneDX SBOM. High and critical findings without an explicit, valid VEX disposition fail the run.
  • Repository secrets are scanned in CI across the full-history boundary and the working tree; every finding must be assessed in a machine-readable ledger, and raw secret values in the ledger or evidence fail the run.
  • The CRA applicability record remains a legal-review artifact and does not claim a classification by itself.

Access control​

  • A fixed role baseline (see First steps and activation); existing roles are never renamed or removed. The permission matrix documents the permissions.
  • Maker and checker are different people. Commission approval checks context hash, amount, currency, recipient, and splits.
  • Activation and readiness endpoints require the Insurance Broker Administrator role. The Setup Manager role cannot activate.
  • Health and claim information uses restricted roles, private files, retention, Legal Hold, and access-audit controls. The cockpit shows a restricted state instead of leaking a count or amount.
  • Cockpit queries are server-side, parameterised, company-scoped, and bounded by a small row limit.
  • Separate, mutually unauthorised broker organisations need separate sites.

Privacy operations​

  • Configure processing purposes and legal bases; handle special categories separately.
  • Use private files, data classification, and the Insurance Broker Sensitive Claims role.
  • Process a data-subject request only after identity and representation checks.
  • Record export, rectification, restriction, deletion, or anonymisation in a Data Subject Request Case.
  • Check the dry run, retention rules, and legal holds before any disposition.

The outbox, exports, communications, files, search indexes, and backups are part of the deletion and restriction scope. The configurable disposition actions are delete, pseudonymise, and retain. The legal-basis table is intentionally empty in the current version; missing, unknown, or unproven mappings fall back to retain, and delete requires proof. No executable Disposition Ledger re-apply path is shipped.

Untrusted input​

Documents, OCR output, model output, and provider payloads are proposals until a human or an admitted policy accepts them. AI capability is blocked by default and no model output may mutate a domain record without admission. Unknown provider schemas are quarantined, not mapped on a best-effort basis.

What this is not​

Insurance Broker Core supports these workflows. It is not a GDPR, Swiss FADP, FINMA, BaFin, FMA, tax, accounting, or insurance-coverage certification, and it does not replace qualified legal review. The bundled regulatory rule contracts are shipped as unapproved; the operator remains responsible for legal basis, country profile, retention policy, and security controls.

Restricted data must never be posted in issues, pull requests, or CI logs; the project's tests use synthetic data only.