Compliance vs Security: Different Goals, Same Budget

Compliance and security are not the same thing. I have tested organizations fully compliant with multiple frameworks yet fell to basic attacks within hours. I have also tested organizations with no formal compliance program that were remarkably well-defended because they focused on what actually mattered. Compliance tells you whether you met a defined standard. Security tells you whether you can withstand a real attack. Both matter, but confusing one for the other is a costly mistake.

Compliance Mindset

The compliance mindset focuses on meeting defined requirements and passing audits. This becomes dangerous when it drives all security decisions.

• Check the box - Whether the control is effective is secondary to whether it exists and is documented. I have seen organizations deploy web application firewalls in detection-only mode to satisfy a requirement, providing zero protection while technically meeting the standard.
• Pass the audit - Auditor satisfaction becomes the objective rather than actual security improvement. The reality of daily operations may differ substantially from what the auditor sees.
• Meet minimum requirements - Standards define a floor, not a ceiling. They also lag behind the threat landscape by years, meaning compliance may not protect against current threats.
• Document everything - Documentation creates accountability, which is genuinely valuable. The problem arises when it becomes the end goal. I have reviewed beautifully documented security programs that existed entirely on paper.

Security Mindset

The security mindset focuses on reducing actual risk and defending against real-world threats.

• Reduce actual risk - Every decision is evaluated based on whether it reduces the probability or impact of an incident. A retail company faces different threats than a manufacturing firm, and investments should reflect that.
• Prevent real attacks - Security-minded organizations think like attackers. They ask "how would someone attack us?" rather than "what does the standard require?" This is why penetration testing is so valuable.
• Continuous improvement - Threats evolve constantly. Compliance is often point-in-time; security must be continuous.
• Defense in depth - Multiple layers ensure a single failure does not result in complete compromise. Many compliance-focused organizations invest in perimeter controls while neglecting internal segmentation and monitoring.

Where They Diverge

Here are real scenarios from my testing experience, with client details removed.

• Compliance: password complexity policy - A client had a compliant policy requiring 12 characters with complexity. I cracked 40 percent of Active Directory passwords in under four hours because users used patterns like "Company2024!" that met requirements but were trivially guessable. Security: multi-factor authentication would have rendered the cracked passwords nearly useless.
• Compliance: annual penetration test - A client tested every December for compliance. They deployed a major application in January with a critical SQL injection that went untested for eleven months. Security: continuous testing integrated into the development lifecycle would have caught this immediately.
• Compliance: firewall review - A client documented quarterly reviews as required, but the same team that created rules reviewed them and no rules were ever removed. Over five years, thousands of overly permissive rules accumulated. Security: independent review would have maintained a tight ruleset.

Balancing Both

The goal is not to abandon compliance but to use it as a foundation for genuine security.

• Use compliance as baseline, not ceiling - Meet every requirement, then ask what else is needed to actually be secure. Build upon the framework based on your specific risk profile.
• Leverage compliance budget for real security - If compliance requires a penetration test, make it thorough rather than a checkbox exercise. Choose implementations that provide genuine security value.
• Document how security exceeds compliance - This demonstrates to auditors and executives that your organization takes security seriously beyond minimum standards.
• Align security initiatives with compliance needs - Map improvements to compliance requirements wherever possible. Projects serving dual purposes are easy approvals for most executives.

The European Regulatory Landscape

For organizations in Slovenia and the broader EU, the regulatory landscape is evolving rapidly. GDPR established the foundation, NIS2 expanded cybersecurity requirements for essential entities, and DORA introduced specific requirements for the financial sector. These regulations increasingly require genuine risk management rather than checkbox exercises. NIS2 requires measures proportionate to actual risks, pushing compliance closer to a security-minded approach. When regulation demands genuine security rather than performative compliance, both objectives are better served.

Practical Recommendations

If I could give every CISO one piece of advice: run a genuine penetration test alongside your compliance audit. The audit tells you what you have documented and implemented. The penetration test tells you what actually works. The gap between those findings is your real risk. I have never seen an organization where there was no gap, and some of the widest gaps were in organizations that considered themselves highly compliant. Use the test results to inform your strategy beyond compliance, and treat compliance as the starting line, not the finish line.