Introduction: What comes first: Compliance or security?

‍
Early in a security and compliance journey, organizations usually face a choice: optimize for a fast certificate (for example ISO 27001) or build the security foundations that reduce real risk (strategy, operating model, culture, and controls). Both paths can be valid, depending on your business model, risk appetite, and stakeholder demands. But whenever compliance certificates are not an urgent must-have for external stakeholders (usually your clients), our experience from 100+ conversations with IT and InfoSec leads over the last months is consistent: Security first wins long term. Even when certification matters, the strongest programs start with security outcomes and then use the framework to structure and prove what is already working.

‍
Why it matters: Companies, and especially mid-market teams do not have time or budget for a parallel reality, one life on paper and another in production. This post explains why (compliance) checklists are not security, common traps we see, and a step-by-step path that aligns protection, culture, and compliance.

‍
Why “compliance-first” backfires in the long run

‍
Compliance ≠ Security

‍
You can pass an audit and still be weak where it matters for your business. On the other hand, if you build a risk-aware, business-fit security program, you will almost always pass audits, often with only a few documentation tweaks. An analogy that might help explain my point: you can pass a driving theory test without becoming a safer driver. The road decides, not the paper.

‍
A moment that changed my mind: Early in my career, I watched a company write a thick stack of policies to “get ISO 27001 done.” None of it matched day-to-day work. The first audit passed with minor notes. The real work started afterwards: versioning documents, collecting screenshots, retraining people on processes they did not use. Two realities emerged: the one on paper and the one in production. Security did not improve, but overhead did.

‍

Frameworks lag the threat landscape

‍
Compliance frameworks evolve more slowly than the threat landscape, and when they are applied as fixed checklists, they can miss emerging risks. While they are designed to drive continuous improvement and encourage risk-based decisions, in practice, many compliance-driven organizations only document risks on paper, but day-to-day focus shifts to implementing the bare minimum of a predefined set of controls.

‍
A recent example is the rapid adoption of AI across companies. Awareness of the new risks is only now catching up in many places. Meanwhile, most frameworks are intentionally high-level and update on multi-year cycles, so they rarely provide detailed, AI-specific controls and guidance for implementation. The result of compliance-driven checkbox execution is predictable: organizations handle these risks the same way they handled the last wave, even though the reality has changed.

‍
Culture beats paperwork

‍
A real security strategy sets direction: what you protect, why it matters, and which risks come first. Culture decides whether that strategy shows up in everyday behavior, how exceptions are handled, whether people escalate early, and whether secure ways of working feel normal or painful.

‍
That is why strategy plus security culture consistently beats a forty-page policy. ISMS documents matter, but they are not the strategy; they are artifacts. If strategy is unclear and culture is weak, documentation becomes a substitute for decisions, and compliance turns into paperwork.

‍
This year I spoke with 100+ IT and InfoSec leaders. Many said some version of, “We passed ISO 27001 and top management is happy, but the structural gaps were not visible on paper. Now we struggle to live up to what is documented.” That gap drains energy, time, and trust, and it slows down both security and compliance progress.

‍
Security vs. compliance, overlapping goals, different engines

‍
Certifications can create real business value. They can unlock customer deals, reduce friction in procurement, satisfy regulator expectations, and give internal stakeholders a shared structure and language for security work. For many companies, a certificate is also a useful forcing function to clarify responsibilities, standardize processes, and build a repeatable baseline.

‍
The important part is understanding what a certificate is, and what it is not. A certificate is a signal to external parties and a point-in-time validation within a recurring audit cycle. It does not automatically mean your security matches your business risks or that controls work smoothly in production, or that your team can respond well when something goes wrong. The value depends on the effort taken during the implementation, your context, scope, and the reason you are pursuing it.

‍
To make this distinction tangible, we like to separate information security and compliance into two circles. They overlap, but they are not the same discipline. The Venn diagram below summarizes the differences, and why “security first” usually makes compliance easier over time.

‍

See venn diagram below:

‍

Your 10-step, security-first agenda

‍
Here is the pattern we see in the companies that mature fastest. They put security first, and compliance tends to follow shortly after because the evidence and structure already exist in how they operate. Instead of building a parallel “audit world,” they build capabilities that work in day-to-day reality, and then map that reality to the framework.

• ‍Clarify whether you truly need the certificate now
  Start with the uncomfortable question: do you need the certificate this year, or do you need better security outcomes? If it is a hard customer or regulator requirement, the answer is clear. If it is a “nice to have,” validate whether certification is the best use of focus at this point in time. Many organizations benefit more from first stabilizing core security basics, then letting certification come naturally once processes and evidence exist.

• ‍Educate management on what the certificate actually means
  Make sure leadership understands what a certification like ISO 27001 covers, what it does not, and what “passing” really implies. A certificate can be a strong foundation and a credible market signal, but it is not proof that your highest business risks are really handled properly. Align on expectations early, including the reality that certification is not a one-off project; it is an ongoing operating commitment.
  ‍
• ‍Do not let urgency break working processes
  If external pressure forces a fast certification, resist the temptation to bolt on controls that nobody will maintain. Consider support that helps you pass the audit quickly while still designing a long-term roadmap that fits your business. Otherwise, you risk building shortcuts that become permanent drag, where teams spend months maintaining paperwork instead of improving security outcomes.
  ‍
• ‍Start with business risks, not with control lists
  Before opening any framework document, write down your top real-world risk scenarios in plain language. Keep them concrete and specific to your environment, for example ransomware on shared storage, credential theft through phishing, data leakage through new AI tools, supplier compromise, or misconfigured cloud access. Then prioritize by impact and likelihood, and validate with stakeholders beyond IT so the list reflects real business exposure.
  ‍‍
• Map controls into real workflows
  For every prioritized risk, ask where it actually lives in day-to-day work. Then place the control there, in the tools and processes people already use. If change management matters, build it into your ticketing and deployment flow. If access risk matters, enforce it in identity and device management. The goal is simple: controls should feel like part of how work gets done, not like extra steps added only to satisfy a policy PDF.
  ‍
• ‍Automate evidence wherever possible
  Prefer tools and workflows that generate logs, approvals, and traceability by default. This turns evidence collection into a byproduct of operating normally. It also removes the need for a parallel audit process where people recreate screenshots and documents just to prove something happened. Automated evidence is usually more reliable, easier to maintain, and less disruptive for teams.
  ‍
• ‍Keep a small set of leadership metrics
  Do not report only “certification achieved” or “percent controls implemented.” Add 5 to 7 KPIs leadership understands and is willing to review regularly. Good examples are estimated financial risk reduced for top scenarios, phishing resilience and reporting rates, restore success and recovery time, coverage of key assets/processes, or maturity versus target. Metrics should support decisions, not just status updates.
  ‍
• ‍Treat frameworks as a cross-check, not the driver
  Fix what is risky in your specific environment first. Then use a framework such as ISO, SOC, or TISAX to validate gaps, structure improvements, and ensure coverage. This keeps the framework useful as a quality check and organizing tool, rather than turning it into a control checklist that dictates priorities even when it does not match today’s reality.
  ‍
• ‍Invest in culture, not just documentation
  Short role-based training, realistic simulations, and simple reporting paths outperform long policies that no one reads. Make secure behavior the easiest behavior by reducing friction, clarifying who decides what, and rewarding early escalation. If people believe security slows them down, they will route around it. If they experience it as practical and supportive, you will see better habits and better outcomes.
  ‍
• ‍Plan day 2 before you get the stamp
  Think beyond the audit window. Plan the next 6 to 12 months so progress continues after certification: access hygiene, incident rehearsal, supplier oversight, and continuous hardening. Build a cadence that keeps improvements moving without burning out the team. The threat landscape changes too fast for a set-and-forget approach, and the companies that stay resilient treat certification as a milestone, not the finish line.