Security & Privacy
1
What if a Finding Is Wrong?
Fair concern — you shouldn't act on findings you can't check.
Our Answer:
Every finding points to specific records in your own system and the reason it was flagged — for example, the exact duplicate record IDs, or the field that came back empty. You can open those records and verify each result yourself. And a person reviews the findings before they reach you, so you're not receiving raw, unchecked machine output. If a finding is wrong, you'll be able to see exactly why it was flagged — and we'll re-scan and re-issue at no cost.
2
If You Miss or Misidentify an Issue, Who's Responsible?
You need clear lines on liability.
Our Answer:
You own every implementation decision. We deliver an advisory report; you decide what to fix, in what order, and with which vendor. Because diagnostics are read-only, nothing we do changes your system, so there's no execution risk on the diagnostic itself. If you later engage us to do hands-on repair work, that happens under a separate signed agreement that spells out scope and responsibility explicitly. Your legal team is welcome to review that agreement before anything is signed.
3
Can Read-Only Access Really Keep Our Data Safe?
Even read-only access is a risk if data leaves your system.
Our Answer:
We connect through a read-only API connection scoped to reporting permissions — the same kind of access your analytics or reporting tools use. We cannot write to, merge, or delete a single record. What we produce is a findings report: counts, grades, and the specific issues we found. We commit in writing to not exfiltrating your raw customer records, and we're glad to walk your security team through exactly what the connection can and cannot do before you grant it.
4
How Do We Know You're Not Training Models on Our Data?
Everyone's heard the stories of proprietary data ending up in a model.
Our Answer:
Written commitment: your customer data is never used to train or fine-tune any model, and never used to improve our service. The tools we use to move quickly through your records don't feed those records into a learning system. We keep a record of what was accessed and when, available to your team. If complete isolation matters to your organization, let's talk about how to structure the engagement to meet that requirement.
5
We're Regulated — Can an Outside Audit Even Comply?
Your compliance team is cautious about outside vendors. Reasonably so.
Our Answer:
The distinction that matters most to your compliance team is read-only versus write access. A service that autonomously changes your database is high-risk under frameworks like GDPR and HIPAA. A read-only diagnostic that scans and reports — and never modifies anything — is a fundamentally lower-risk posture, and the entire FMCF diagnostic model is built that way on purpose. On formal attestations: we are actively pursuing SOC 2 and the supporting compliance documentation, expected through 2026, and we're glad to share our current status and timeline with your GRC team rather than overstate where we are. In the meantime, we put our data-handling commitments in a written agreement your team can review before you engage, and we'll show you exactly how the read-only architecture maps to your requirements.
6
What About Insurance and Liability Coverage?
Carriers have grown cautious about outside data vendors.
Our Answer:
Because diagnostics are read-only and never change your system, the risk profile is inherently lower than a service that writes to your data. We are in the process of putting formal Errors & Omissions and cyber-liability coverage in place, expected through 2026, and we'll share certificates directly once they're issued. For any hands-on implementation work — which happens only under a separate agreement — we're glad to align on risk-allocation terms with your procurement team before anything is signed. We'd rather tell you plainly where our coverage stands than imply more than we can document.