What Is Security Compliance? Challenges and Best Practices

NIS2 is the broadest EU security framework by sector coverage. It applies to essential and important entities across energy, transport, banking, financial market infrastructures, health, drinking water, waste water, digital infrastructure, ICT service management, public administration, space, postal services, waste management, chemicals, food, manufacturing, digital providers, and research. Article 21 requires these entities to implement cybersecurity risk-management measures covering ten categories: risk analysis and information system security policies, incident handling, business continuity, supply chain security, security in systems acquisition and development, effectiveness assessment, cyber hygiene and training, cryptography, human resources security and access control, and multi-factor authentication. The proportionality principle in Article 21(1) calibrates the expected depth of measures to entity size and risk exposure.

DORA applies specifically to financial entities — credit institutions, payment institutions, investment firms, insurance undertakings, and numerous other categories listed in Article 2 — plus critical ICT third-party service providers designated by the ESAs. DORA's security requirements are more detailed than NIS2's: Article 9 prescribes specific protection and prevention measures including network security management requirements, access rights management, and change management procedures. Article 10 requires anomaly detection capabilities and multiple layers of detection controls. Article 11 mandates comprehensive ICT business continuity policies with explicit recovery time and recovery point objectives. For entities subject to both NIS2 and DORA, DORA operates as lex specialis — its more specific requirements take precedence, but NIS2 obligations not covered by DORA still apply.

GDPR approaches security from the data protection perspective. Article 32 requires data controllers and processors to implement technical and organisational measures appropriate to the risk, explicitly mentioning pseudonymisation, encryption, confidentiality/integrity/availability assurance, resilience, restoration capability, and regular testing. Article 25 embeds security into system design through data protection by design and by default. These requirements overlap substantially with NIS2 and DORA but are triggered by personal data processing rather than sectoral designation. ISO 27001, while not EU legislation, functions as a de facto compliance framework — NIS2 Recital 79 acknowledges that international standards like ISO/IEC 27001 can be taken into account when implementing cybersecurity measures, and many supervisory authorities reference it as a benchmark.

Adopt a risk-based approach to security compliance rather than a checklist approach. Both NIS2 Article 21(1) and DORA Article 6(1) root their requirements in risk management — measures must be appropriate to the risk. A risk-based approach means identifying and assessing the specific threats to your organisation, evaluating the likelihood and impact of those threats, and implementing controls proportionate to the assessed risk. This produces a defensible compliance posture: when a supervisory authority questions why you implemented a particular control at a certain depth, you can explain the risk assessment that informed the decision. A checklist approach — implementing controls to a uniform depth regardless of risk — either over-invests in low-risk areas or under-invests in high-risk areas, and provides no defensible rationale for either.

Embed security compliance into operational processes rather than maintaining it as a parallel activity. The most effective compliance programmes are invisible to end users because compliance controls are built into the workflows people use daily. Access reviews happen through the identity platform, not through a separate compliance spreadsheet. Vulnerability remediation flows through the same ticketing system as operational work, with compliance-driven SLAs attached. Incident classification triggers regulatory reporting automatically, without requiring someone to remember to also file the regulatory notification. This integration reduces compliance burden on operational teams and produces more reliable evidence — controls that operate as part of normal business processes are more likely to function consistently than those that depend on someone remembering to perform a separate compliance activity.

Invest in automation for repeatable compliance activities. Evidence collection, control testing for configuration-based controls, compliance reporting, and regulatory change monitoring are all candidates for automation. Automation reduces the human effort required for compliance maintenance, improves consistency (automated checks produce the same result every time, unlike manual reviews that vary by reviewer), and enables continuous compliance monitoring rather than periodic compliance snapshots. The automation investment compounds over time: each automated control reduces the ongoing operational cost of compliance, freeing resources for the judgment-intensive activities — risk assessment, control design, incident analysis — where human expertise is irreplaceable.

Sustained security compliance requires more than tools and processes — it requires a culture where compliance is understood as integral to the organisation's operations rather than as an external imposition. This cultural dimension is implicit in NIS2's management body training requirement (Article 20(2)) and DORA's awareness programme mandate (Article 13(6)): regulations increasingly recognise that technical controls fail when the people operating them do not understand or value compliance objectives. Building this culture starts at the top — when the management body treats compliance as a strategic priority rather than a cost centre, the rest of the organisation follows.

Translate regulatory obligations into operational language that resonates with non-compliance personnel. Engineers do not need to know the article numbers; they need to know what they must do differently and why it matters. Frame compliance requirements as operational quality standards: access reviews protect the organisation from insider threats, not just from regulatory fines. Incident reporting procedures ensure the organisation can respond effectively under pressure, not just satisfy a notification timeline. Vulnerability management keeps systems reliable and secure, not just audit-ready. When people understand the operational rationale behind compliance activities, they engage with those activities more willingly and execute them more reliably.

Measure and reinforce compliance culture through operational indicators. Track the percentage of security incidents reported through proper channels (versus discovered through other means), the timeliness of control owner evidence submissions (do owners submit on time or does the compliance team chase repeatedly?), the participation rate in optional security training beyond mandatory minimums, and the frequency of compliance-relevant questions from the business to the compliance team (a sign of engagement rather than avoidance). Recognise and publicise compliance successes — when a team identifies and reports a near-miss, when an access review catches an orphaned privileged account, when an incident response drill completes within regulatory timelines. Positive reinforcement builds the culture more effectively than punitive enforcement, though both have their place.