These questions come from compliance officers and legal teams I've spoken with as EU courts and the European Commission increasingly signal that certain national digital laws don't apply when EU regulations govern the field. This pattern is creating confusion for teams managing multi-jurisdictional compliance programs, especially around data protection, platform regulation, and digital services. Here's what you're asking.
Do national data protection laws still apply alongside the General Data Protection Regulation?
It depends on what the national law is trying to regulate. The General Data Protection Regulation (GDPR) establishes a harmonized framework across all member states. When a national law attempts to add requirements or restrictions in areas the GDPR already covers, EU courts have increasingly found those national provisions inapplicable.
You'll still comply with national implementations of GDPR provisions, like the specific supervisory authority structure in each country or sector-specific carve-outs the regulation explicitly permits. But if a member state passes a digital law that contradicts or extends GDPR requirements for lawful basis, Data Minimisation, or the 72-hour notification requirement, expect that national provision to face legal challenge.
Your practical step: map your current compliance obligations by legal basis. Separate genuine GDPR requirements from national additions. Flag the national-only requirements for legal review, especially if they're creating compliance friction or blocking cross-border data flows your GDPR Article 44-50 mechanisms already permit.
How does this affect our Statement of Applicability if we're ISO/IEC 27001 certified?
Your Statement of Applicability documents which ISO/IEC 27001 and ISO/IEC 27002 controls you've implemented and why. The EU's stance on national law applicability doesn't change your certification obligations, but it should influence how you justify control selection.
If you previously cited a national digital law as the reason for implementing a specific control, and that law is now considered inapplicable, your justification weakens. You'll need to tie the control back to the GDPR, eIDAS, the Digital Services Act, or another applicable EU regulation instead.
During your next surveillance or recertification audit, auditors will examine whether your legal and regulatory requirements inventory (typically part of Annex A control 5.31) accurately reflects current obligations. If you're still listing inapplicable national laws, you're creating audit findings and potentially over-investing in controls you don't legally need.
What happens to our consent management if national laws required stricter consent than the General Data Protection Regulation?
You revert to GDPR Article 7 requirements: consent must be freely given, specific, informed, and unambiguous. If your Consent Management Platform currently implements national requirements that go beyond this standard (perhaps requiring explicit opt-in language beyond what Article 7 mandates, or prohibiting legitimate interest as a lawful basis in contexts the GDPR permits), you're potentially over-restricting your data processing.
The risk here cuts both ways. If you remove national-law-driven consent requirements and a court later upholds that national provision, you've created a compliance gap. If you keep them and they're genuinely inapplicable, you're limiting business flexibility for no legal reason.
Your move: document the legal basis for every consent requirement in your Consent Management Platform configuration. Where you've implemented national provisions that exceed GDPR Article 7, get legal sign-off on whether to maintain them as internal policy or remove them as no longer required. Don't let your technical implementation drift from your legal position.
Should we still comply with national cybersecurity laws if EU regulations cover the same ground?
This is where the EU Commission's position creates the most operational tension. If you're subject to the NIS2 Directive (implemented through national laws) and also to sector-specific national cybersecurity requirements, you need to identify where those national rules duplicate or conflict with NIS2 obligations.
The principle emerging from EU courts is that member states can't add cybersecurity obligations in areas already harmonized at EU level. But they can implement the discretion EU directives explicitly give them. Your challenge is distinguishing between the two.
Consider a scenario where your national regulator requires annual penetration testing for critical infrastructure, but NIS2 leaves testing frequency to organizational risk assessment. If a court finds that national annual requirement inapplicable, you're still obligated to conduct testing under NIS2 Article 21's risk management measures, but the frequency becomes your decision based on your ISO 31000 or NIST Risk Management Framework methodology.
Don't unilaterally stop complying with national requirements. Instead, build a compliance matrix that maps each national obligation to its EU-level equivalent. Where there's a gap or conflict, document it and seek legal guidance on enforceability.
How do we handle Data Subject Access Requests when national laws added requirements beyond Articles 15-22?
Process them according to GDPR Articles 15-22, period. If your national law required you to provide additional information categories, shorter response times than the regulation's one-month window, or different identity verification procedures, and those requirements aren't found in the GDPR itself, they're likely the type of national additions courts are finding inapplicable.
Your Data Subject Access Request procedures should cite specific GDPR articles for every step. When you verify identity, you're complying with Article 12(6). When you respond within 30 days, you're meeting Article 12(3). When you extend that deadline, you're using Article 12(3)'s explicit two-month extension provision.
If your current procedures reference national law provisions for these steps, update your documentation. The underlying process might not change, but your legal justification must point to EU law, not national additions.
What's the risk if we keep complying with national laws that might not apply?
Over-compliance isn't usually a legal risk, but it's an operational and competitive one. You're potentially restricting data processing activities your competitors aren't restricting, implementing controls that don't map to actual legal obligations, and creating vendor requirements that slow procurement without regulatory justification.
The bigger risk is inconsistency. If your French subsidiary complies with French national digital laws the EU Commission considers inapplicable, but your German subsidiary doesn't comply with equivalent German provisions, you've created an unexplainable gap in your compliance program. Auditors and regulators will ask why the same data processing has different controls in different countries when you're operating under a harmonized EU framework.
Where do we go from here?
Conduct a legal basis audit across your compliance program. Every control, procedure, and restriction you've implemented for "regulatory compliance" should trace to a specific, currently applicable legal requirement. Where that requirement is a national law in an area the GDPR or another EU regulation already covers, flag it for legal review.
Don't make compliance changes based solely on EU Commission statements or even lower court rulings. Wait for definitive guidance from the Court of Justice of the European Union or from your Data Protection Authority. But start preparing now by understanding which of your requirements rest on potentially inapplicable national law.
Your compliance program should be built on EU regulations first, with national law filling only the gaps those regulations explicitly leave open. If you've built the opposite way, with national law as your foundation, you're facing a significant documentation and possibly technical remediation project.
