I have watched a company with a Palo Alto-equipped SOC fail an audit, while a competitor running basic firewalls sailed through. Same sector, similar budgets, opposite outcomes. After fifteen years and hundreds of assessments—TISAX for automotive suppliers, PCI-DSS for retailers, ISO 27001 for manufacturers, NIS2 readiness for almost everyone—I have stopped finding that surprising.
The lessons that explain it don’t appear in any framework or certification guide. They are about what actually matters, what doesn’t, and why some organisations breeze through audits while others struggle despite spending more on security.
These are the things I wish someone had told me when I started. They shape how I work today, and they are why I eventually built tools to fix the problems I kept seeing.
Lesson 1: Documentation Beats Technology
The most counterintuitive lesson: strong security often fails audits, weak security often passes. The difference is documentation.
I’ve seen Palo Alto-equipped SOCs fail TISAX assessments because they couldn’t produce change records. I’ve seen companies running basic pfSense firewalls pass ISO 27001 because every decision was documented, justified, and traceable.
Auditors can’t assess what they can’t see. Your controls may be excellent, but without evidence to demonstrate them, you fail. As BSI guidance makes clear, audit evidence matters as much as the controls themselves.
This isn’t documentation over substance. It’s documentation of substance. Build good security and document it. Either one without the other fails.
Lesson 2: Compliance Is a Floor, Not a Ceiling
Early in my career, I thought compliance meant security. Pass the audit, you’re secure. Fail it, you’re not.
Experience taught me otherwise. Frameworks set the minimum acceptable standard. Meeting them makes you compliant, not secure. Many breached organisations were fully compliant on the day they were breached.
Compliance is the starting point, not the destination. The best organisations I’ve worked with treat frameworks as foundations to build on, not checklists to complete.
Chasing compliance without understanding security creates dangerous false confidence. You can tick every box and still be exposed. The ENISA threat landscape reports are full of compliant organisations that got breached.
Lesson 3: Process Over Products
Vendors sell products. Frameworks require processes. The gap between the two causes most failures.
I’ve seen companies buy every tool on the Gartner Magic Quadrant and still fail. Tools without process are just expensive equipment. Process with modest tools often passes.
A €50,000 SIEM that nobody monitors is worth less than a €5,000 log aggregator with defined review procedures. The tool doesn’t matter when the process doesn’t exist.
Assessments focus on process evidence: how do you detect threats, what happens when you do, who is responsible, and how do you know it works? Products support these processes; they don’t replace them.
Lesson 4: Continuous Beats Annual
The traditional model: prepare frantically for the annual audit, pass, ignore security for eleven months, repeat. That model is dying.
Modern frameworks like NIS2 assume continuous compliance. Auditors increasingly turn up unannounced. Incident reporting requirements mean you can’t hide problems until the next cycle.
Organisations that fold compliance into daily operations—security as normal work, not a special project—do better over the long run. They have no “audit season” because every day is audit-ready.
Continuous compliance also costs less. The pre-audit scramble of overtime, consultants and emergency fixes disappears. According to industry research, it reduces total audit costs by 30-40%.
Lesson 5: People Are the Bottleneck
Technical controls are easy. People are hard. Every failed audit I’ve investigated traced back to human factors: training gaps, unclear responsibilities, process breakdowns, or simple mistakes.
The engineer who bypassed change management “just this once.” The manager who approved without reading. The team that forgot to document an emergency change. People, not technology, cause compliance failures.
Programmes that succeed invest heavily in people: clear roles, practical training, and processes reasonable enough that humans will actually follow them. Tools should support judgement, not replace it.
I design for human nature, not against it. A cumbersome process gets bypassed. So make the right thing to do the easy thing to do.
Lesson 6: Risk-Based Thinking Wins
Checklist compliance—treating every requirement as equal—wastes resources and misses the real risks. The best programmes are risk-based: more investment where risk is higher, less where it’s lower.
ISO 27001 explicitly requires a risk-based approach, and NIS2 follows the same principle. Auditors expect you to explain why you implemented a control, not just that you did.
“We implemented this control because our risk assessment identified X threat to Y asset with Z impact” is a passing answer. “We implemented it because the framework said to” is not.
Compliance should flow from risk assessment, not the reverse. Understand your risks first, then choose controls that address them. The framework is a tool, not a substitute for thinking.
Lesson 7: Management Sets the Tone
Security culture comes from the top. When executives treat compliance as a cost centre to minimise, the organisation follows suit. When they treat security as a business enabler, everything changes.
The strongest programmes I’ve seen had visible executive sponsorship: board-level reporting, security as a standing agenda item, and budgets that matched stated priorities.
NIS2 makes this explicit with management liability provisions. But the principle was always true: a programme succeeds or fails on management commitment.
If you’re struggling with security culture, look at management behaviour first. Do they model the practices they expect from others? Do they fund security properly? Do they hold people accountable?
Lesson 8: Perfect Is the Enemy of Done
I’ve watched companies delay compliance for years chasing the “perfect” solution. Meanwhile they stay non-compliant and exposed.
Good enough and implemented beats perfect and planned. An 80% solution deployed today gives you more security than a 100% solution still in committee.
This isn’t an excuse for poor security. It’s pragmatic prioritisation: tackle the biggest risks first, improve continuously, and don’t let perfection paralyse progress.
Compliance is a journey, not a destination. You’ll never be “done.” Accept that, start where you are, and improve systematically.
Lesson 9: Vendors Aren’t Your Friends
Vendors sell products. Their goal is revenue, not your compliance. The “complete solution” they promise usually needs further purchases, professional services and ongoing subscriptions.
I’ve seen companies buy tools they didn’t need because a vendor framed them as compliance requirements. I’ve seen budgets swallowed by enterprise platforms when open-source tools would have done the job.
Be sceptical of vendor compliance claims. Ask for specific mapping to requirements. Verify with independent sources. The BSI’s IT-Grundschutz catalogue provides vendor-neutral guidance.
This shaped my own product work. I built FwChange to solve a real problem, priced for mid-market budgets, without the enterprise complexity that adds cost without value.
Lesson 10: Compliance Should Be a Byproduct
The best programmes don’t focus on compliance at all. They focus on good security practice, and compliance follows as a byproduct of doing security well.
When security is embedded in operations—risk-informed decisions, documented changes, trained staff, tested procedures—the audit evidence generates itself. You’re not preparing for audits; you’re operating securely, and audits simply confirm what’s already true.
Organisations that chase compliance as the goal often achieve neither compliance nor security. Those that pursue genuine security usually achieve both.
That is the synthesis of everything I’ve learned: build real security, document it properly, and compliance follows. The reverse doesn’t work.
Applying These Lessons
After 15 years, I still run assessments and help organisations get to compliance. But now I also build tools that put these lessons into practice.
FwChange exists because documentation should be automatic — and because mid-market companies deserve compliance tools that don’t require enterprise budgets.
If you’re facing TISAX, NIS2, ISO 27001 or any other compliance challenge, these lessons hold. Focus on documentation. Build processes, not just products. Make it continuous. Invest in people. Think risk-based.
And if you need help, reach out. I’ve spent 15 years learning these the hard way so you don’t have to.
About the Author
Nick Falshaw is a security consultant with 15+ years experience in enterprise security compliance across the DACH region. He’s the founder of FwChange, building compliance tools for mid-market companies. Connect on LinkedIn.