Assume Error: What Creative QA Can Learn From Cybersecurity

In cybersecurity, one of the most useful shifts in thinking is learning not to design systems around perfect behavior.

You do not assume every request is legitimate. You do not assume every user will follow the intended flow. You do not assume every configuration will remain correct forever. You build controls because eventually something will go wrong.

Creative work deserves the same mindset.

Marketing agencies, design teams, developers, copywriters, content teams, and now AI-assisted workflows often operate under an assumption that is rarely stated explicitly:

The person creating the work should get it right.

And, of course, they should try.

They should proofread their copy. Developers should test their work. Designers should check their layouts. Campaign managers should verify dates, prices, links, audiences, and offers. AI-generated content should be reviewed before publication.

But there is an important difference between expecting professionalism and designing a process that depends on perfection.

The first is reasonable.

The second is fragile.

People Will Make Mistakes

Everyone makes mistakes.

That statement can sound like an excuse, but operationally it should mean the opposite.

If we know that mistakes are inevitable, then professional processes should be designed around that reality.

A copywriter can proofread a post and still miss a typo.

A developer can test a form and overlook an unexpected state.

A designer can stare at the same layout for hours and stop noticing something that is immediately obvious to a fresh pair of eyes.

A project manager can paste the wrong date.

A client can provide outdated information.

An automated workflow can propagate incorrect source data perfectly.

And an LLM can produce fluent, convincing output that is simply wrong.

These failures do not all happen for the same technical reasons, but they lead to the same operational conclusion:

Output requires verification.

The solution to human error cannot simply be asking humans to stop making errors.

The same is true for AI.

The solution to unreliable output cannot simply be another prompt saying, "Make sure everything is correct."

At some point, the process itself has to become responsible for verification.

Cybersecurity Already Understands This

Security professionals do not generally build defensive strategies around the hope that nothing bad will ever happen.

We add authentication because requests cannot automatically be trusted.

We use least privilege because accounts may be compromised or misused.

We create monitoring because preventative controls can fail.

We maintain backups because data can be corrupted, deleted, encrypted, or lost.

We perform security reviews because developers can introduce vulnerabilities without realizing it.

We separate systems because one failure should not automatically become every system's failure.

The philosophy is not pessimistic.

It is resilient.

The same idea can be applied to creative QA:

Assume error.

Not because your people are incompetent.

Because they are people.

And increasingly, because part of the work may be produced by systems that are also capable of producing convincing mistakes.

"Assume error" does not mean accepting bad work.

It means refusing to make perfection a dependency of the system.

A Typo Is Not Just a Typo

Consider something trivial: a spelling mistake in a social media post.

Internally, it may be nearly meaningless.

Someone writes the post. Another team member notices the typo.

It gets corrected.

Nothing happened.

No customer saw it. The client never knew about it. The agency's reputation was unaffected.

That was not a quality incident.

That was quality assurance working.

Now imagine the same typo is published.

Maybe nobody notices.

The agency fixes it later.

Life continues.

Now change the context again.

The client sees it first.

The conversation is no longer about spelling.

It may become:

"Why am I paying an agency if they cannot proofread a post?"

The technical defect has not changed.

The business impact has.

Now go one step further.

The client's customer notices it.

The client is no longer simply evaluating the agency's work. The agency has exposed the client's brand to the mistake.

The failure has crossed another boundary of trust.

One small creative defect has now put two separate relationships under strain, and the agency controls neither of them from where it is standing.

If the client is already questioning the relationship, that tiny typo could contribute to cancellation.

The typo may still be objectively minor.

The consequence may be critical.

That distinction is familiar in cybersecurity.

A flaw is not important only because of what the flaw looks like in isolation. Context, exposure, affected systems, and potential consequences matter.

Creative QA often lacks an equivalent way of thinking.

We tend to label things informally:

• "Just a typo."
• "Small design issue."
• "Broken link."
• "Wrong date."

But the real question should be:

What could happen if this escapes?

That question deserves an answer more precise than a shrug, and it is the subject of the next article in this series: Not Every Typo Is Low Severity.

The Error and the Incident Are Different Things

This distinction matters.

A mistake can exist without becoming an incident.

A wrong date discovered during internal QA is a defect.

A wrong date in an email delivered to 50,000 subscribers may be an incident.

The underlying mistake is identical.

What changed was its ability to escape the controls around it.

This gives us a more useful way to think about quality:

Creating a defect and allowing a defect to escape are not the same event.

That matters because many organizations accidentally punish the first one so aggressively that they weaken their ability to prevent the second.

If someone says "I found an error" and the immediate response is "Who did it?", the organization has just taught everyone something.

Finding problems is dangerous.

People learn to minimize findings.

They become defensive.

They quietly fix mistakes instead of documenting patterns.

Review becomes personal.

QA becomes something done to the creator rather than something done for the work.

The organization may still claim that quality matters, while unintentionally creating incentives that make quality problems harder to see.

Cybersecurity has learned versions of this lesson repeatedly.

You want vulnerabilities reported internally.

You want unusual activity surfaced.

You want people to raise concerns before an attacker, customer, regulator, or journalist does it for you.

Creative organizations should want the same thing.

Finding an Error Should Be a Win

A team that reports a lot of internal findings is usually described as having a quality problem.

It may be describing the opposite.

Finding many internal defects does not necessarily mean quality is getting worse. It may mean visibility is getting better.

A mature quality organization should care far more about what reaches the client than about making its internal numbers look clean.

So a dangerous metric is:

"How many mistakes did the team make?"

And a better question is:

"How effectively did our process contain them?"

Those two questions produce completely different organizations, and the arithmetic that separates them is sharper than it first looks. It gets its own article later in this series, Stop Counting Mistakes. Start Measuring Escapes.

The cultural version is simple enough to state now.

An internal finding is potential impact prevented, not someone failed.

This does not mean performance never matters. If someone consistently produces unreliable work, skips required checks, or repeatedly submits unverified information, that pattern needs attention.

But an individual defect is not automatically evidence of negligence.

A pattern is a signal. A signal should trigger investigation before judgment. And telling the two apart is hard enough that it gets its own article too, When Does a Mistake Become a Pattern?

Blame-Free Does Not Mean Accountability-Free

This is where quality conversations usually become polarized.

One side says: "Everyone makes mistakes."

The other responds: "So we are just supposed to accept bad work?"

No.

A healthy QA culture should be able to hold two ideas at the same time: errors are expected, and professional controls are expected too.

Someone who follows a reasonable process, verifies what matters, and still occasionally misses something is being human. Someone working without any verification process at all is inside a process failure. Someone with no time to review is inside a capacity problem. Those situations produce identical defects and require completely different responses, which is why the distinction deserves an article of its own: A Blame-Free Culture Is Not an Accountability-Free Culture.

The principle underneath it comes from security, and it is short.

An alert is not a verdict.

It tells you where to investigate.

Red-Team the Work, Not the People

Security teams use adversarial thinking because normal use does not reveal every weakness. You do not find the hole by walking through the front door correctly.

Creative work benefits from the same attitude.

Before something is released, somebody should be allowed to approach it with a deliberately hostile question:

What is wrong with this?

Not "can I approve it quickly?" Not "does it basically look okay?"

Turning that question into an actual review technique (for copy, for layouts, for campaigns, for a checkout flow) is the subject of the next article in this series, Red-Team the Work, Not the People.

What belongs here is the cultural boundary it depends on:

The work should be challenged adversarially. The people should not be treated as adversaries.

That distinction may be the most important part of the entire system.

You want reviewers motivated to find things.

You want creators comfortable receiving findings.

You want people saying "great catch" rather than defending why the mistake happened.

You want the team competing against escaped defects, not against each other.

Trust Is the Real Asset Being Protected

In agency work, QA is often described as protecting quality.

That is true, but incomplete.

The thing being protected is trust.

Clients trust agencies with their brands.

They trust developers with their websites.

They trust campaign managers with budgets.

They trust copywriters with public communication.

They trust designers with perception.

And their customers usually do not distinguish between the agency and the client when something goes wrong.

They simply see the brand.

So the work does not simply travel outward from the team. It travels through a series of relationships, and each one it crosses changes who absorbs the consequence.

That structure has its own mechanics, and they are the subject of the third article in this series, The Trust Chain.

What matters here is the conclusion it leads to: creative QA should not simply count mistakes.

It should think about containment.

Assume Error

The phrase "Assume Error" is not an argument for lowering standards.

It is an argument for building better ones.

It means:

1. Do excellent work.
2. Review your own work.
3. Use checklists where they make sense.
4. Automate checks that machines can perform reliably.
5. Use independent reviewers when the impact justifies it.
6. Verify high-risk information.
7. Treat client-visible errors differently from internal catches.
8. Learn from recurring patterns.
9. Improve the process.

And most importantly, stop pretending that quality is achieved by assembling a group of people who simply never make mistakes.

That team does not exist.

The better goal is to build a team that is exceptionally good at catching mistakes before they matter.

Cybersecurity has spent decades learning to distrust assumptions, layer controls, detect failures, contain damage, and treat incidents as opportunities to improve systems.

Creative organizations can learn from the same philosophy.

Not because a typo is a cyberattack.

Not because a bad crop is a vulnerability.

But because both disciplines ultimately confront the same uncomfortable reality:

Something will eventually go wrong.

The question is what happens next.

A fragile process hopes nobody makes the mistake.

A resilient process assumes someone eventually will.

And catches it before the client does.