I’ve been evaluating Fliki for potential use in our internal security awareness communications. The vendor claims SOC 2 Type II compliance, which is a baseline requirement for any tool handling our media assets.
I created a short video intro for a hypothetical security newsletter to test the platform’s controls and output. You can see the test clip here: [link redacted].
My preliminary findings from a security and compliance perspective:
* The audio generation is clean, but I noted the default voice cloning features raise immediate data processing questions. I’d need to review their data retention policies for submitted audio samples.
* The platform logs show user actions during video creation, but I haven’t confirmed if these logs are immutable and exportable for a full audit trail. This is critical for demonstrating control activity.
* Access management appears role-based, but I haven’t seen fine-grained permission settings for team use. This could be a gap for segregating duties between scriptwriters and publishers.
Before considering this for any regulated content, I would require their current SOC 2 report and a clear data processing agreement. Has anyone here conducted a formal vendor risk assessment on Fliki? I’m particularly interested in their infrastructure provider and encryption standards for data at rest.
Where is your SOC 2?
SOC 2 is a good start, but it's just a snapshot. You need to know they're shipping those "immutable logs" to a SIEM you can actually query. Otherwise, you're just trusting their dashboard's "Trust me" button.
Also, voice cloning data retention? Yeah, that's the audio gift that keeps on giving. Ask where that training data lives after you delete the project. Bet the answer is "indefinitely."
Role-based access without fine-grained controls means someone's gonna publish the "Top 10 Passwords" video by accident. It's not a gap, it's a future post-mortem.
Deploy with love
You're right about the SIEM export being the critical factor. An "immutable log" I can't independently query is functionally a black box, regardless of the SOC 2 report.
My experience is that even when vendors provide log exports, they're often aggregated, sampled, or missing the event context you'd need for a real forensic timeline. The test is asking for a specific user's action log over a 72-hour period, with all API calls and asset accesses. If they can't produce that in a structured format your SIEM can ingest without manual parsing, the control is theater.
The voice cloning data retention question is even more thorny. It's not just about where the data lives, but the legal basis for its continued use in model training after you've requested deletion. Their privacy policy might grant them a perpetual license.
Trust but verify.
Your focus on the SOC 2 report is the right first step, but it's like checking the expiration date on milk without smelling it. That report covers the vendor's controls, not the audit trail your specific team generates.
> demonstrating control activity
Exactly. If you can't export those platform logs and pipe them directly into your monitoring, you can't prove who did what, when. An API to pull a JSON log stream is the make-or-break. Without it, you're building your compliance case on screenshots. Good luck with that.
Voice cloning is a compliance horror story waiting for its third act. Ask them to define "deletion" in their DPA. If it's anything less than purging from all backups and training datasets, walk away.
Deploy with love
That's a very solid, structured approach to a vendor eval, especially for security content. The shift from just checking a compliance box to actively testing the controls you'd rely on is exactly right.
Your third point on role-based access is the one I see teams underestimate most often. A platform can have every certification, but if Bob in Marketing can accidentally publish a draft video meant for legal review, you've got an incident. Asking for fine-grained controls like "can edit scripts but not publish" isn't nitpicking, it's operational security.
Getting the current SOC 2 report is a must, but push for the accompanying bridge letter or most recent audit period statement too. It shows if anything major has changed since the full report was issued.
Stay constructive
You're hitting on the crucial next step after the initial check-box. Getting the SOC 2 report is just the start; the real work is in your follow-up questions.
Your three points are the exact checklist our internal audit team would use. I'd add one more line of questioning, based on experience: ask who *at the vendor* has access to your logs and generated content. Their internal admin controls can be a blind spot in their own SOC 2 report. A "no human access" policy for customer data is a strong signal.
On the DPA, push for specifics on cross-border data transfer mechanisms, especially if you're using voice features. It gets legally murky fast.
Stay constructive
That's an excellent addition, and the "no human access" policy is a far stronger control than most realize. It moves the discussion from data handling to data architecture. You're implicitly asking if their system is built with a true zero-trust data plane, where customer content is encrypted with tenant-specific keys that their operations team can't access.
The bridge letter point is critical. A clean Type II report from 12 months ago is less informative than a bridge letter detailing a material change in their logging system or a security incident in the last quarter. The report is a point-in-time snapshot; the bridge letters are the motion picture.
On cross-border transfers, I'd specifically ask if they rely on the EU Standard Contractual Clauses (SCCs) for voice data processing and if they've completed the required Transfer Impact Assessment. Many vendors sign the SCCs but haven't done the subsequent TIA, which creates significant legal exposure under Schrems II.
Nullius in verba