Written By: David Carneal - Digital Efficiency Consulting Group
Read time: 8 minutes

There's a pattern that shows up in almost every regulated organization, and once you see it, it can't be unseen. A requirement gets introduced-usually reasonable, sometimes even simple. But because it's tied to regulation, the organization treats it differently. It gets elevated, it gets protected, it gets expanded and somewhere between the original intent and the implementation meeting where stake holders & non-vested parties alike people are debating the approval routing, it becomes something the standard never actually asked for.

This is exactly what happens with ISO 13485. Let's be honest for a second - this happens when the word regulatory appears. Mind you, this is not because the ISO 13485 standard is flawed, or any other standard for that matter, but because the moment someone heard regulations someone flipped a switch and everything got complicated just to prove its being taken seriously. The way companies interpret and operationalize tends to drift in one predictable direction: more structure, more steps, more control mechanisms, more documentation… more everything. The intention is good. The outcome, more often than people like to admit, isn't.

What starts as an effort to ensure compliance often turns into a system that is difficult to execute, impossible to maintain, and increasingly disconnected from how work actually happens inside the organization. Once that disconnect exists, compliance doesn't fail all at once. It erodes quietly, inside the workflow, one workaround at a time. This is where the auditors observations start creeping in - and if you know, you know.

What the Standard Actually Says-and Doesn't

ISO 13485 requires that organizations control changes, manage documents, handle complaints, investigate issues, and maintain traceability. That's the substance of it, but somehow, without fail, people love to make it complicated. The funny part is what the standard doesn't specify: How work should move between people, how decisions should flow, how long each step should take, how systems should interact, or how real-world chaos should be handled when things don't go according to the process map someone printed and laminated three years ago. These are the pieces that end up bringing down the house of cards.

That part is the organization's job. That's where design choices matter. The moment you take a regulatory requirement and turn it into a process, you're no longer dealing with compliance alone - you're dealing with workflow design, whether you realize it or not. Who owns the step? Who hands it off? Where does the information live? What happens when something stalls? What happens when something is urgent and can't wait for Tuesday's change control meeting? If those questions aren't answered clearly, the process might still exist on paper, but the workflow underneath it will fail and people will begin improvising to make it work. Most organizations believe they are building controlled processes. What they often build instead are layered sequences of tasks that look controlled on a flowchart and behave completely unpredictably when actual humans try to use them under pressure.

Change Control: A Study in Two Realities

Take something as simple and straightforward as change control. The intent is to evaluate the impact of a change, make an informed decision, document it, and ensure traceability. A simple enough process that it fits in a single sentence. But the real question isn't "Do we have a change control process?" It's "How does this change actually move through the organization when someone is waiting for it?"

A functional workflow starts with a change initiated in a single area of the business. Ownership is clear from the start. The responsible person evaluates impact, pulling in input from SME, only when necessary. One or two relevant stakeholders review and approve-in parallel, not sequentially. The decision is recorded in the same place where the work lives. Implementation is tracked. The process closes cleanly. The whole thing is unremarkable, which is exactly the point. But what happens if it isn't?

A complex, overbuilt workflow looks and acts very differently. A change is initiated in one system, evaluated in another, and documented in a third. At some point someone decided that each function needed its own system of record, which is a great way to triple your administrative overhead while reducing actual visibility by affected parties. Ownership shifts as the process moves between departments. Multiple teams are required to review regardless of whether the change affects them, because someone once said "we should keep everyone in the loop" and that became policy by tribal knowledge. Approvals are sequential, not parallel, so delays compound. Information is duplicated. Teams create side trackers to maintain organization in a system theoretically designed to provide it. Urgent changes bypass the process entirely to get documented later, which everyone agrees is a problem that no one actually fixes.

"Both workflows satisfy the same regulatory requirement. But from an execution standpoint, they are completely different systems. One is designed to move work efficiently and quickly, the other is designed to look important."

Friction Is the Gremlin

Regulations don’t fail processes. Friction does. And friction is embarrassingly simple to spot - it shows up the moment following the process takes more effort than going around it. Once that happens, people don’t become careless. They become rational. They have actual work to do and the process is in the way. That’s it. That’s the whole problem!

People approve things in conversations because the system is too slow. They document after-the-fact because real-time entry is too disruptive. They maintain separate trackers because the official system doesn't reflect reality. These aren't random behaviors. They are signals. They're telling you the workflow doesn't support execution, and when execution moves outside the process, compliance dies.

Most organizations misdiagnose this as a discipline problem. Of course, people need more training. Of course, teams need to follow procedures more closely. Of course, compliance needs to be enforced. Very few companies want to admit the uncomfortable possibility that the process itself may be the problem, especially after spending months building it, documenting it, and convincing everyone it was the "controlled" way to work.

In reality, the issue is usually structural. Workflow friction tends to appear in the same places over and over again. Approval friction shows up when simple decisions require multiple signoffs, creating delays because half the approvers are in meetings, on vacation, or not even directly involved in the change. Handoff friction appears when work moves between departments without clear ownership, so tasks stall while teams quietly assume someone else is handling it. System friction happens when information lives in multiple disconnected platforms and employees spend more time reconciling records than actually moving work forward. Exception friction appears when something slightly unusual happens, a rush order, missing information, a supplier delay, an engineering clarification, and suddenly nobody knows how the process is supposed to handle it because the workflow was designed only for the "perfect scenario." Visibility friction develops when no one can clearly see where work actually stands, which is why side spreadsheets, sticky notes, whiteboards, and shadow tracking systems begin appearing across the organization like operational survival tools.

Individually, each friction point seems manageable. Together, they completely reshape how work actually flows through the business, usually without leadership realizing it until audit findings, delays, customer complaints, or operational fatigue begin surfacing downstream. And none of this complexity is required by ISO 13485.

CAPA: Where Complexity Goes to Thrive

CAPA is one of the best places to observe this dynamic because it touches multiple parts of the organization and involves both investigation and corrective action. These are two things that benefit greatly from clarity and suffer enormously from bureaucracy. The requirement is conceptually simple: identify an issue, determine root cause, implement corrective action, verify effectiveness. Straightforward in theory, yet surprisingly easy to ruin in practice.

Nobody likes CAPAs. Not the people who open them, not the people who own them, and definitely not the people who have to close them six months later while pretending the corrective action actually corrected something. The only thing worse than a CAPA is a CAPA system that makes the whole experience slower, more painful, and somehow less effective than just fixing the problem and moving on.

A CAPA that works - and yes, they can work - logs the issue, assigns an owner immediately, and gets out of the way. The investigation level matches the severity of the problem. A mislabeled box doesn’t need a five-tool root cause analysis. A systemic process failure does. The people who approve the corrective action should be the people the issue actually affects - not a cross-functional committee assembled because someone decided that consistency meant inviting everyone. Implementation gets tracked. Effectiveness gets verified. The record closes. Nobody throws a party, but nobody loses six weeks of their life either.

A CAPA system built for appearance works very differently. The issue gets logged in one system, investigated in another, and documented in a third - because somewhere along the way, three separate teams decided they each needed their own system of record, and nobody had the authority or the energy to push back. Root cause analysis follows a mandatory template regardless of whether the problem warrants it, because someone built the template and now it’s policy. Approval groups that have nothing to do with the issue still have to sign off, because consistency got confused with relevance again. Timelines drive closure instead of verification. And when it’s all done, the record looks impressively thorough - right up until the same issue comes back six months later and everyone acts surprised. Or Not.

From a documentation standpoint, the second process looks stronger. From a workflow standpoint, it's weaker at every step.

Processes Fail When Reality Shows Up

Simple processes flex. They adapt because ownership is clear and the path is understandable. Complex processes struggle. They depend on multiple steps, multiple people, and multiple systems all working in sequence. When one piece slows down, everything slows down. An urgent issue comes in. A key person is unavailable. A system goes down. Workload spikes. Suddenly the elegant process map on the wall has nothing useful to say about what happens next, and people start improvising.

Complaint handling is another area where this plays out clearly. The requirement is to receive, evaluate, investigate, and respond. A workflow that works keeps complaints in one system. Ownership is assigned immediately. Evaluation determines next steps. Findings and actions are recorded in the same place. Response is issued. The record closes. A workflow that struggles spreads complaints across multiple tools, requires reviews that don't always add value, separates communication from documentation, and produces records that are technically compliant but operationally useless.

Why Complexity Accumulates and Why It Stays

There’s another reality most organizations discover the hard way: it’s easy to add complexity and nearly impossible to remove it. Not for political reasons, but structural ones. Every step that gets added becomes load-bearing over time. It was written into the process to compensate for something else, to hand off to the next step, to feed information forward. Pull one step out and you don’t have a simpler process. You have a broken one. Now you’re not simplifying, you’re rebuilding. And rebuilding a process that’s actively in use, inside a regulated environment, while people are still trying to use it, is exactly as fun as it sounds. This is why complexity accumulates and stays. Not because anyone loves it, but because the cost of untangling it is real and immediate, while the cost of keeping it is slow and easy to ignore.

This is why starting simple matters so much. If you begin with a clean, functional workflow and add structure only when a specific problem requires it, you maintain control without creating drag. If you start complex because complexity feels safer, you spend years trying to unwind decisions that made sense in isolation and don't make sense together. The organizations that do develop systems aren't the ones with the most rigorous processes. They're the ones that asked harder questions upfront: Does this step add control, or does it add steps? Does this approval add value, or does it merely add a signature?

A Workflow-First Approach

The alternative is to start with how work actually moves. Map the flow. Identify where decisions happen, where delays occur, where information gets lost, where people rely on memory and side channels instead of the systems you paid for. Then, design the process to support that flow, not override it. This is the difference between documenting a process and designing one. Documentation describes what should happen. Process design accounts for what actually does happen once real people, competing priorities, interruptions, system limitations, urgent requests, missing information, and operational pressure get involved.

A documented process may say a quality review takes place before release, but good workflow design asks harder questions. What happens if the reviewer is unavailable? What happens if the order is urgent? What happens if engineering clarification is needed halfway through? What happens when three departments all believe someone else owns the next step?

Documentation defines the intended path. Workflow design determines whether the path actually survives contact with reality.

Once you understand the flow, you can see clearly where complexity is helping and where it's creating friction. You can make intentional choices about what to add and what to leave out, instead of accumulating requirements until the process collapses under its own weight, then wondering why people aren't following it.

At the end of the day, compliance is not about how much process you have. It's about how well your process aligns with execution. If your documented process and your actual workflow match, you have control. If they don't, you have exposure and an audit that's going to be a lot more exciting than you wanted.

ISO 13485 doesn't require complexity. It requires consistency, traceability, and control. Those things don't come from adding more steps. They come from designing processes that people can actually follow under real conditions, with real workloads, and real urgency.

If your processes feel heavy, if your teams rely on workarounds & if audits feel like a cleanup effort rather than a confirmation of what's already working, the issue isn't that you need more structure. It's that your workflow and your process are out of sync. In most cases, the fix isn't adding more. It's removing what doesn't belong and rebuilding around how work actually moves. The strongest compliance system isn't the one with the most documentation. It's the one that holds up when real work runs through it.

If any of this felt familiar, that’s not a coincidence. These patterns show up across every industry, regulated or not, and they have one thing in common: they are costing you money right now. Not eventually. Now. Quietly, consistently, every day your workflow runs the way it currently runs.

DECG has spent years inside operations exactly like yours, mapping workflows, finding the drag, and rebuilding processes that actually work. Not theoretical frameworks. Not software implementations. Actual work, done in days, not months.

Here’s the part most companies don’t see until someone shows them: you don’t have a growth problem. You have a leaking pipe. You’re looking at new tools, new advertising, new investments to grow the business, while somewhere inside your operation money is walking out the door one inefficient step at a time. Fix the leak first. The growth gets a lot easier to fund when you stop hemorrhaging what you already have.

A workflow audit with DECG takes a few days and a fraction of what the problem is already costing you. Most clients are genuinely surprised by what we find. Some are horrified. All of them are better off for knowing.

The question isn’t whether the problem exists. It’s whether you want to find it.

ABOUT THE AUTHOR

David Carneal is the founder of Digital Efficiency Consulting Group (DECG), an operational efficiency and workflow diagnostics advisory firm specializing in process design, workflow analysis, and operational improvement. With more than 25 years of experience across manufacturing, distribution, and service organizations, he focuses on identifying the hidden friction that slows execution, increases operational drag, and creates disconnects between documented procedures and how work actually moves through a business. His work centers on simplifying operational complexity while maintaining practical control, accountability, and scalability.

David frequently collaborates with regulatory and compliance specialists to help organizations bridge the gap between operational execution and regulatory expectations. While regulatory consultants often focus on interpreting standards, audit readiness, and compliance requirements, David's role centers on how those requirements function operationally inside the business, including workflow design, process flow, cross-department coordination, and the day-to-day realities of execution once procedures leave the document and enter the real world.

CTA: If your workflow feels heavier than the work itself, it may be time for a workflow audit.