Why compliance fails even when intentions are good  

Most compliance failures don’t come from neglect, shortcuts, or bad actors. They come from good intentions.  Companies want to do the right thing. They invest time, money, and energy into policies, frameworks, certification and loads of documentation. Yet when audits happen, a pattern appears again and again: what is written down does not match how the business actually operates. That gap is where compliance quietly breaks.   The Top Three Reasons Causes of Faillure: 1. The problem isn’t effort, it’s abstraction  One of the most common mistakes is how policies are written.  They are often full of well-intended but abstract language:  
  • “We monitor systems” 
  • “We ensure appropriate security measures” 
  • “We have controls in place” 
On paper, this sounds responsible. In practice, it creates risk.   As Karolin Kruiskamp, founder of Compleye, puts it:  “Policies often describe what you should have, not what you actually do. And that’s where the mismatch starts.”   When documentation describes an ideal future state instead of today’s reality, teams unknowingly set themselves up for failure. Not because they are doing things wrong, but because they are describing a version of the business that doesn’t exist yet.   Auditors don’t expect perfection. They expect consistency. 2. One business, many realities Another reason compliance fails despite good intentions is over-generalisation. Businesses are complex systems. A website, a customer-facing product, internal tools, employee laptops, and databases all carry different risks. Yet policies often treat them as one homogeneous environment.   Karolin highlights this disconnect clearly: “Web filtering for a company website is very different from web filtering for an application. Data protection on a laptop is not the same as data protection in a database.”   When everything is covered by one generic rule, nothing is truly covered. Teams struggle to apply policies in real situations because the guidance is too broad to be useful.   The result is confusion, workarounds, and documentation that looks compliant but doesn’t guide daily decisions.   3. Compliance fails where ownership disappears Good intentions also fail when responsibility is diffused.  When policies are vague, it’s unclear who owns what. Teams assume “someone else” is handling it. Tools are integrated, dashboards are generated, but no one can clearly explain what is being monitored, why it matters, or what happens when something changes.   Karolin consistently returns to this point:  “Compliance only works when someone takes the time to be specific and to really think through what is relevant and what is not.” Compliance is not a documentation exercise. It is a decision-making exercise.   The fix is uncomfortable, but simple Fixing this problem does not require more tools, more documents, or more controls.   It requires honesty.  
  • Writing down what you actually do, not what you aspire to do.
  • Being explicit about differences between systems and components 
  • Acknowledging gaps and improvement plans instead of hiding them in abstract language  
      As Karolin notes, when companies do this, audits rarely become critical:  “If you’ve thought about it and you can explain your choices, it will almost never be a critical non-conformity.”    Compliance as a mirror of how a business really runs In the end, compliance doesn’t fail because people don’t care. It fails because growing businesses change faster than their documentation, and abstraction feels safer than specificity. But abstraction hides reality. And compliance, by its nature, always exposes it.  The companies that succeed are not the ones with the most polished policies, but the ones willing to describe themselves honestly — including the parts that are still evolving.   Or as Karolin summarises it simply:  “Compliance is about stopping for a moment to think about what you’re doing, so you can be sure you’re doing it right.”   That pause is often all it takes to close the gap between good intentions and real control. 

      Want to see where your reality and documentation diverge? The gap usually isn’t visible from inside the organisation.

      It only becomes clear when someone walks through your policies together with you and simply asks: “Show me how this works in practice.”

      We regularly sit down with leadership teams to map that difference, not as an audit, but as a working session. The goal is clarity: what already works, what is unclear, and what only lives on paper. If you’re curious what that would look like for your organisation, let’s plan a short conversation. No preparation needed, just bring how things actually run today.

      Frequently Asked Questions

      Why do companies fail ISO 27001 or SOC 2 audits even when they have policies in place?

      The most common cause is a gap between what the policy says and what the business actually does. Policies often describe an ideal future state, in abstract wording such as “we ensure appropriate security measures”. When an auditor asks to see how it works in practice, the evidence does not match. Good intentions are rarely the problem. The mismatch between paper and reality is.

      No. Auditors look for consistency, meaning that what you document matches what you do and that you can show evidence of it. A policy that honestly describes your current practice, including known gaps and a plan to close them, usually holds up better than a polished one that describes something that does not exist yet.

      1. Pick a policy. Start with one that auditors always check, such as access control or incident response.
      2. Ask the owner to show you. Have them walk through how it works today, step by step.
      3. Compare it to the text. Note every difference between the walkthrough and the written policy.
      4. Check the evidence. Look for logs, tickets or records that prove it happened.
      5. Fix one side. Either change the practice or rewrite the policy to describe reality.

      A single generic rule rarely fits every part of a business. A website, a customer-facing application, employee laptops and databases all carry different risks and need different controls. When one rule covers everything, teams struggle to apply it, create workarounds and end up with documentation that looks compliant but does not guide daily decisions.

      A short working session with a compliance specialist can surface differences that are hard to see from inside the organization. It works best as a walkthrough of how things really run, not as an audit. You bring how your team operates today, and together you identify what already works, what is unclear and what only exists on paper.