Building Defenses: Verification & Response Protocols

You Need a Reflex, Not Just Awareness

Think about what you do when your bank calls about a suspicious charge. If you're careful, you don't just trust the voice on the line. You hang up, and you call back on the number printed on your card. Same person, same question, but now you know who you're really talking to.

That small habit is the whole idea behind defending against deepfakes. Up to this point in the path, we've talked a lot about awareness: what deepfakes are, how they're made, and how to spot the red flags. But awareness on its own tends to collapse the moment someone is urgent, senior, and convincing. Awareness helps you notice the problem. A reliable process helps you respond to it.

So in this video, we're going to turn everything you've learned into a repeatable response. We'll walk through the core workflow, the procedural controls that actually stop this kind of fraud, the technical controls that back them up, and how to report it when it happens. Let's get into it.

The Core Workflow: Red Flag, Verify, Escalate

So, in the last video, we introduced a simple response to a suspicious request: red flag, verify, escalate.

You already know how to recognize the warning signs. Now we're going to focus on what happens next: how to verify a request, how to escalate it, and what controls make that process reliable.

You saw this checklist back when we talked about spotting deepfakes. Here's where it stops being a poster on the wall and becomes something you actually do.

A red flag is the pattern, not the pixels. You're not trying to catch a glitch in the video anymore. You're noticing the situation: a request that's urgent, secret, comes from someone senior, arrives on an unusual channel, or asks you to move money, credentials, or access. Any of those on its own is worth a second look. Together, they're a stop sign.

Verify means you confirm the request through a channel you already trust, not the one the request came in on. If a "colleague" messages you on a new number, you call them on the number in your directory. Notice the request itself never has to be proven fake. You just have to confirm it's real before you act.

And escalate means you don't keep it to yourself. You report it to your security or fraud team, and you hold on to whatever you saw: the message, the number, the recording. Even if you dodged it, that report helps protect everyone behind you. Now let's break down the controls that make each of these steps stick.

Procedural Controls That Actually Work

So what actually stops a deepfake-enabled scam? In many cases, the strongest defense is a process, not a piece of software. Let's start with one of the most important controls: out-of-band verification.

Out-of-band just means using a different, trusted channel to confirm a request. Someone calls claiming to be your CFO? You hang up and reach them on the number already in your company directory. The FBI's own guidance says it plainly: verify the person by hanging up, looking up the organization yourself, and calling back directly. Caller ID can be faked. A familiar voice can be cloned. The channel you chose in advance can't be handed to you by an attacker.

For families and executives, add a code word. This is a simple phrase you agree on ahead of time, and it's one of the FBI's specific recommendations for the "help, it's me, I'm in trouble" voice-cloning calls. If the voice can't produce the word, the voice doesn't get the money.

And for anything that moves money or grants access, require a second person. Dual authorization means one convincing request, even one that looks and sounds exactly like your boss, can't complete the action alone. Remember the finance worker who wired about twenty-five million dollars off a video call full of fake colleagues? A mandatory callback and a second approver turn that from a content problem, where you have to detect the fake, into an account-control problem, where the fake simply can't finish the job.

Technical Controls That Support Them

Now, technology absolutely helps, as long as we're honest about its job. Technical controls support the human process. They don't replace it.

Start with multi-factor authentication that doesn't depend on a face or a voice. If your login or your approval can be satisfied by "sounds like the right person," then a good enough clone is a valid credential. A hardware key or an app-based token can't be cloned from a podcast clip, so it stays strong even when the media doesn't.

Next, put limits and confirmation around money movement. Transaction limits, hold periods, and an out-of-band confirmation for new payees mean that even a successful impersonation runs into a wall it can't talk its way past. These controls don't care whether the request was fake. They slow every high-risk action down to a speed where verification can happen.

And finally, provenance and detection. When we looked at detection and provenance, we were careful about this: these are supporting signals, not verdicts. Provenance standards like Content Credentials can tell you where a piece of media came from, and a detector can raise a flag. But a missing credential is not proof of a fake, and a clean scan is not proof it's real. Feed those signals into your process. Don't let them be the process.

When It Happens: Report, Preserve, Learn

So let's say a request gets through your first instinct and you're not sure. What then? This is the escalate step, and speed matters more than certainty.

Contact your security or fraud team right away. If money already moved, that early call is what gives a bank a chance to freeze or claw back a transfer. You don't need to have proven anything. A suspected fraud is enough to act on.

While you do that, preserve the evidence. Save the messages, the phone numbers, the email headers, any recording of the call. Don't clean it up, don't delete the thread. That trail is what lets investigators trace the attack and warn the next target.

And here's the one people skip: report the near misses. The request you caught is just as valuable as the one that landed. Every near miss teaches your organization what the current playbook looks like, so the next person sees it coming. Reporting isn't admitting you almost fell for it. It's how the whole team gets stronger.

A Quick Word on the Rules

Now, a brief word on the rules, because the legal landscape is shifting, and you should know it's there. We're keeping this short on purpose.

In the European Union, the AI Act's Article 50 brings transparency obligations that apply from August second, twenty twenty-six. In plain terms, organizations that use AI to create a deepfake generally have to disclose that the content is artificially generated or manipulated. In the United States, the TAKE IT DOWN Act now requires covered platforms to remove non-consensual intimate images, including deepfakes, within forty-eight hours of a valid request, and the FTC began enforcing that in May of twenty twenty-six.

Here's the thing to hold on to. These rules help. They push disclosure and give victims a path to act. But a fraudster using an unmarked, open tool isn't going to follow the disclosure rules. So regulation shapes the environment around you. It does not do your verification for you. The reflex still has to be yours.

Summary: Key Takeaways

So let's pull it together. The strongest defense against a deepfake isn't a better eye or a better detector. It's a better process. Verify the request, don't grade the media.

Run the same three steps every time: red flag, verify, escalate. Lean on the controls that actually hold under pressure: an out-of-band callback on a number you already trust, a pre-agreed code word, and a second approver for anything that moves money or access. Back those with MFA that isn't your face or voice, and transaction limits that buy you time. And when something slips through, report it fast, preserve what you saw, and share the near misses so the next person is ready.