NIS2 Art.38 Confidentiality and Data Protection: What NCAs Can Share, What They Must Protect, and How This Affects Your Audit Exposure — Developer Guide 2026

NIS2 Article 38 is the confidentiality and data protection anchor for the entire supervisory regime. It is short — two core obligations — but it quietly governs what happens to your company's information once it enters the hands of a national competent authority (NCA).

Developers focusing on Art.21 security measures or the Art.35/36 penalty regime tend to overlook Art.38. That is a mistake. Understanding Art.38 tells you what your NCA can and cannot do with the technical details, incident data, and audit findings they collect from you — and it shapes how you approach NCA cooperation when an investigation begins.

1. What Art.38 Says

NIS2 Art.38 contains two primary obligations:

Art.38(1) — Professional Secrecy:

"Member States shall ensure that competent authorities, CSIRTs, single points of contact and persons acting under their authority are bound by the obligations of professional secrecy with regard to confidential information obtained in the exercise of their tasks and activities, in accordance with Union or national law."

Art.38(2) — GDPR Application:

"Without prejudice to Regulation (EU) 2016/679, personal data obtained in the exercise of the tasks and activities referred to in this Directive shall be processed and exchanged only to the extent necessary for the purposes of this Directive."

Together, these two provisions create a data governance framework around everything your NCA knows about you.

2. Professional Secrecy: What NCAs Cannot Share

Art.38(1) binds NCA staff to professional secrecy — the same concept used in financial regulation (MiFID II, Solvency II) and healthcare (eHealth frameworks). The practical effect is that:

What is Protected

• Technical audit findings — vulnerability reports, penetration test results, security architecture assessments collected during NCA inspections
• Incident details — the specifics of what happened, what systems were affected, what data may have been exposed, during a significant incident investigation
• Business information — network topology, vendor relationships, software stack details disclosed to NCAs as part of Art.21 compliance evidence
• Financial information — revenue data used to calculate potential Art.35/36 penalties, which the NCA may have obtained during the supervisory process

The Trigger: "Confidential"

The protection only applies to information that qualifies as confidential. This is not automatic — it depends on the nature of the information and the context. In practice:

• Technical security details are presumptively confidential (disclosing them creates new risk)
• Information already in the public domain is not protected
• Regulatory decisions (the NCA's ultimate finding and penalty) are generally not confidential — they are published under Art.35(3) name-and-shame provisions

Who is Bound

The obligation extends to:

• NCA staff and management
• CSIRT personnel
• Single points of contact (SPOCs) under Art.9
• "Persons acting under their authority" — external consultants, seconded experts, technical assessors commissioned by the NCA

This last category matters: if an NCA hires a consulting firm to help conduct an Art.35 supervisory review, those consultants are bound by the same professional secrecy as the NCA staff themselves.

3. Cross-Border Information Sharing Under Art.38

Art.38 does not prohibit information exchange — NIS2 is built on information sharing across the CSIRT Network, ENISA, and the NIS Cooperation Group. But it constrains it.

Permitted Sharing

What Cannot Be Shared

An NCA cannot share your confidential information with:

• A competitor (even under FOIA-style requests, information that would harm competitive interests is protected)
• Other regulatory authorities outside NIS2 scope without a proper legal basis
• Third countries without an adequacy decision or equivalent safeguard

The critical practical point: if an NCA in Germany receives confidential technical details from your company during a supervisory review, they cannot simply pass those details to the French NCA (ANSSI) because the French NCA asked. They need a specific legal basis under Art.16 mutual assistance, and the receiving authority inherits the confidentiality obligations.

4. GDPR Integration: The Art.38(2) Dimension

Art.38(2) does something structurally important: it integrates GDPR into the NIS2 supervisory process. Personal data processed by NCAs during their NIS2 tasks is simultaneously subject to GDPR.

What Personal Data is Involved?

During NIS2 supervisory procedures, NCAs typically collect or process personal data in these categories:

The "Minimum Necessary" Constraint

Art.38(2) states that personal data "shall be processed and exchanged only to the extent necessary" for NIS2 purposes. This is the GDPR data minimisation principle (Art.5(1)(c) GDPR) applied to NCA operations.

Practical implications:

1. NCAs cannot keep personal data indefinitely — once the supervisory purpose is complete, retention must be justified under GDPR retention principles
2. Cross-border sharing of personal data (e.g., sharing incident logs containing employee identifiers with another Member State's NCA) requires a GDPR lawful basis in addition to the NIS2 Art.16 mutual assistance pathway
3. Subject access requests — employees whose personal data was processed by an NCA during a NIS2 investigation have GDPR rights, including the right to know what was processed

Who is the GDPR Controller?

When an NCA processes personal data for NIS2 supervision:

• The NCA is the controller for data it independently collects and processes
• The entity under investigation may be the controller for data it provides to the NCA (e.g., providing incident logs — the entity makes that disclosure decision)

This distinction matters if there is a data breach at the NCA level — who is liable for the GDPR failure?

5. Practical Developer Perspective: The Art.38 Shield

Art.38 gives companies an important procedural tool during NCA interactions. Understanding the professional secrecy obligation allows you to:

5.1 Cooperate More Fully

Many companies are reluctant to share technical details with regulators because they fear those details becoming public. Art.38(1) addresses this: confidential technical information shared with an NCA is protected from disclosure by professional secrecy.

This is structurally similar to how legal professional privilege works — you can share sensitive information in a regulated context with confidence that it will not leak to competitors or become public record.

5.2 Structure Your Disclosures

When providing information to an NCA (whether proactively or in response to a supervisory inquiry), structure your submission to make clear what is confidential:

# Example: Structuring an NCA incident notification
class NCASubmission:
    public_information: dict      # Company name, incident date, sector
    confidential_technical: dict  # CVE IDs, affected system details, logs
    protected_personal_data: dict # Employee/user contact data — GDPR minimised

    def generate_submission_letter(self) -> str:
        """
        Explicit confidentiality assertion for technical and personal data sections.
        References Art.38(1) NIS2 and Art.5(1)(c) GDPR as applicable constraints.
        """
        header = (
            "The technical details in Section B are submitted in confidence "
            "pursuant to Art.38(1) NIS2 Directive (EU) 2022/2555. "
            "Personal data in Section C is provided under Art.38(2) NIS2 "
            "and processed pursuant to GDPR Art.6(1)(c) (legal obligation). "
            "Disclosure outside the supervisory proceeding would require "
            "independent legal basis."
        )
        return header

5.3 Request Confidentiality Protections Proactively

Before a supervisory review begins, consider writing to the NCA to:

1. Identify which categories of information you will provide are confidential
2. Request explicit confirmation that Art.38(1) protections apply
3. Clarify the GDPR lawful basis the NCA is relying on for personal data processing

Most NCAs will not proactively offer this clarity — you need to ask.

6. Art.38 and the Whistleblower Angle

NIS2 Art.38 has a less-discussed interaction with the EU Whistleblower Protection Directive (2019/1937). Companies that receive NCA confidential information (e.g., as part of a joint investigation or peer review process) are themselves bound by professional secrecy constraints.

This creates a structurally unusual situation for internal whistleblowers:

• An employee who discloses that their company is providing false information to an NCA is protected under the Whistleblower Directive
• But the substance of what they disclose may be NCA-protected confidential information that the company received from the NCA
• The interplay between Art.38 confidentiality and whistleblower protection is unresolved across most Member States and will likely require national court resolution

For developers: if you work on systems that interact with NCA supervisory processes, your legal team needs to have thought through this intersection before it becomes live.

7. Member State Implementation Variations

Art.38 leaves implementation details to Member States. Key variations:

The investigation exception under GDPR Art.23 is worth noting: Member States can restrict data subject rights (access, rectification, erasure) when those rights would prejudice an ongoing NIS2 supervisory investigation. This is the same mechanism used in financial crime and antitrust investigations.

8. Audit Logs and Art.38: A Practical Intersection

One of the most common questions developers face: do your system logs collected during an NCA audit become the NCA's property?

The answer is no — Art.38 makes clear that:

1. Personal data in those logs remains subject to GDPR regardless of who holds it
2. The NCA cannot retain logs longer than necessary for the supervisory purpose
3. The entity that provided the logs does not lose its own legal rights over that data

Practically, what you should do before any NCA engagement:

# Pre-audit data minimisation checklist
class AuditLogPreparation:
    
    def minimise_personal_data(self, raw_logs: list) -> list:
        """Remove or pseudonymise personal identifiers before NCA submission."""
        return [self._pseudonymise(log) for log in raw_logs]
    
    def document_retention_expectation(self) -> dict:
        """
        Explicitly state expected NCA retention period in submission cover letter.
        Art.38(2): processed 'only to the extent necessary for the purposes 
        of this Directive' — include expected audit completion date as reference.
        """
        return {
            "expected_audit_completion": "90 days from submission",
            "data_minimisation_applied": True,
            "gdpr_lawful_basis": "Art.6(1)(c) — legal obligation",
            "retention_expectation": "Delete or anonymise within 12 months of audit close"
        }

This approach documents that you took GDPR minimisation seriously, provides a clear paper trail, and sets up a basis for requesting deletion after the audit is complete.

9. What Art.38 Does Not Protect

Art.38 has important limits:

The NCA's decision is not confidential. Art.35(3) explicitly requires NCAs to publish enforcement decisions — the name of the entity, the violation, and the penalty. Art.38's professional secrecy protects the process and underlying data, not the outcome.

Aggregate anonymised data can be shared freely. ENISA publishes sector-wide incident data, benchmarking reports, and threat landscapes. Art.38 does not block this — it only constrains individually identifiable company information.

Court proceedings may override secrecy. If an Art.37 criminal referral results in prosecution, court proceedings are generally public. The technical details that were Art.38-protected in the NCA phase may become accessible through the court record.

10. Compliance Checklist

For developers and security teams building NIS2-compliant processes:

Before an NCA interaction:

• Classify what information you hold that would be shared with NCAs (technical vs. public vs. personal)
• Identify which categories qualify as confidential under Art.38(1)
• Apply GDPR data minimisation to any personal data before providing to NCA
• Prepare a submission cover letter that asserts Art.38 protections explicitly

During NCA supervision:

• Request written confirmation of Art.38(1) confidentiality protections for technical disclosures
• Track all personal data provided (categories, volume, dates) for GDPR accountability
• Clarify NCA's GDPR lawful basis for processing employee data included in audit submissions
• Maintain internal log of all information provided to NCA

After NCA proceedings:

• Request confirmation that audit data has been deleted or anonymised in line with Art.38(2) data minimisation
• Update your GDPR record of processing activities to include NCA data sharing as a disclosure category
• Review whether any court proceedings arising from NCA referrals create ongoing confidentiality implications

Conclusion

NIS2 Art.38 is the regulatory confidentiality wrapper around everything that happens when an NCA examines your organisation. Its professional secrecy obligation protects your technical details and business information from unauthorised disclosure. Its GDPR integration ensures that personal data processed during supervision stays subject to data protection law regardless of who holds it.

For developers, the practical takeaway is twofold: Art.38 gives you a legitimate basis to cooperate more fully with NCAs (your disclosures are protected), and it gives you procedural tools to manage what the NCA retains and shares. Neither tool is automatic — you need to assert Art.38 protections explicitly and build the documentation habit before an investigation begins.

The next article in this series covers NIS2 Art.39–40: Peer Reviews and EU-CyCLONe, the cross-border crisis coordination mechanism that activates when a cyber incident affects multiple Member States simultaneously.