NIS2 principles in practice

More control over documents.
A stronger NIS2 approach.

We apply NIS2 principles through concrete security measures in anonimize. Reduce sensitive information in documents and control access, processing and export. The platform helps your organisation reduce risk.

The Belgian context

Who does NIS2 apply to?

NIS2 concerns the security of network and information systems. Whether Belgian law applies to your organisation depends on factors including sector, activity, size and establishment, taking account of group relationships, exceptions and designations. Registration may also be required. Check the criteria with Belgium’s CCB.

Customers may also set security requirements for suppliers that fall outside the legal scope. Anonimize supports a defined part of this approach: secure document processing and controlled sharing.

Our own approach

Turning NIS2 principles into concrete security.

We substantiate our approach with existing features and controls. Below, we explain what the platform does and what your organisation must arrange. MFA, retention periods, export approval and your own vault key require configuration or activation.

Protecting information

Less exposure, more control.

  • Document detection and OCR on our server in Prague, without a generative AI service.
  • Encrypted document content and reversal mappings, with an optional vault key in your browser.
  • Separate organisations and project permissions, with a separate review before an approved export.

Verification and maintenance

Evidence of actions and safeguards.

  • Audit trails of document actions record the user, time and version, without document content in the trail.
  • Optional two-step verification and configurable retention periods for results and reversal keys.
  • Automated tests, pinned software dependencies and daily backups of encrypted document data.

From requirement to practice

The main requirements, explained.

Article 21 of the NIS2 Directive sets out ten areas of risk management. Belgium’s implementation also requires a coordinated vulnerability disclosure policy. A document platform provides specific measures; the organisation manages the whole. Read Article 21.

  1. Risk analysis and security policies

    NIS2 · 21(2)(a)

    Policies to identify and manage risks to systems and information.

    Our contribution
    Anonymisation and pseudonymisation reduce the exposure of personal data. Project permissions and retention periods support your chosen policy.
    Within your organisation
    Define risks, responsibilities, classification and acceptable residual risk; document your decisions.
  2. Incident handling

    NIS2 · 21(2)(b)

    Detect, assess and handle incidents.

    Our contribution
    Document audit trails help establish who did what. Security questions can be sent to info@anonimize.eu.
    Within your organisation
    Arrange detection, escalation, response and any required notification to the Belgian CCB. An audit trail does not automatically report an incident.
  3. Continuity and recovery

    NIS2 · 21(2)(c)

    Arrange backups, disaster recovery and crisis management.

    Our contribution
    Daily backups of encrypted document data support recovery. Your own vault key remains under your control.
    Within your organisation
    Store your key securely, set recovery objectives and test your continuity plan. Backups alone do not demonstrate a successful recovery test.
  4. Supply chain security

    NIS2 · 21(2)(d)

    Assess risks involving direct suppliers and service providers.

    Our contribution
    Our security page explains processing, European document hosting and security features.
    Within your organisation
    Assess us and other suppliers, agree suitable terms and include dependencies in your risk analysis.
  5. Secure development and vulnerabilities

    NIS2 · 21(2)(e)

    Secure acquisition, development and maintenance, including vulnerability handling and disclosure.

    Our contribution
    Automated tests and pinned software dependencies help us manage changes.
    Within your organisation
    Assess security across your environment. Establish a coordinated vulnerability disclosure policy; a contact address alone is not sufficient.
  6. Assessing effectiveness

    NIS2 · 21(2)(f)

    Check whether security measures work in practice.

    Our contribution
    Permissions, export approvals and audit trails allow specific checks on your document process.
    Within your organisation
    Review risks and measures periodically. Product features do not replace your own assessment or an independent audit.
  7. Cyber hygiene and training

    NIS2 · 21(2)(g)

    Good security habits and appropriate staff training.

    Our contribution
    Review before export helps people consider detections and sensitive context.
    Within your organisation
    Train staff, keep systems current and organise safe working practices. Check each result before sharing.
  8. Cryptography and encryption

    NIS2 · 21(2)(h)

    Appropriate policies for cryptography and the use of encryption.

    Our contribution
    Sensitive document content is encrypted in storage. You can enable additional browser encryption with your own AES-256-GCM vault key.
    Within your organisation
    Manage key access and backup copies. The server temporarily reads source content for detection and OCR; this is not full end-to-end encryption.
  9. People, access and assets

    NIS2 · 21(2)(i)

    Align access with roles and manage information and systems.

    Our contribution
    Organisation and project permissions limit access. A separate reviewer can approve an export; the last editor cannot approve it themselves.
    Within your organisation
    Manage onboarding, role changes and departures. Review permissions and maintain an inventory of information and systems.
  10. MFA and secure communication

    NIS2 · 21(2)(j)

    Use multifactor authentication and secure communication where appropriate.

    Our contribution
    Authenticator-based two-step verification is available, and connections to the app use HTTPS.
    Within your organisation
    Enable MFA; the platform does not enforce it for every user. Protect email, emergency communication and other systems too.

When something goes wrong

Reporting needs a process of its own.

For significant incidents subject to notification in Belgium, the following sequence generally applies, without undue delay. The initial deadlines run from awareness of the incident; the month runs from the incident notification.

  1. 24 hours

    Early warning

    An initial warning to the competent authority.

  2. 72 hours

    Incident notification

    An initial assessment of severity, impact and available indicators.

  3. 1 month

    Final report

    Due within one month after the incident notification; an ongoing incident first requires a progress report.

Trust service providers must also submit the incident notification within 24 hours. Your organisation determines whether an incident must be reported and arranges notification; anonimize does not submit it automatically. Consult the Belgian CCB guidance.

Good to know

What does this mean for you?

Updated on

Does using anonimize automatically make us NIS2-compliant?

NIS2 compliance covers your whole organisation: management, people, processes, systems and suppliers. Anonimize provides demonstrable technical measures for document processing. Your organisation must configure them appropriately and include them in its broader security policy.

What does ‘working according to NIS2 principles’ mean for anonimize?

We link existing safeguards to specific NIS2 themes, including access control, encryption and traceability. A full assessment also requires evidence about scope, governance, procedures and operation in practice. This page substantiates our technical approach; full legal NIS2 compliance has not been established by this explanation.

How does anonymisation help with NIS2?

Removing unnecessary identifying data before sharing a document or using an AI tool reduces exposure if unintended access occurs. This supports risk management. Re-identifiable pseudonyms remain personal data; detections and context still need review. Read GDPR Article 4(5) and Recital 26.

Which settings do I need to enable?

Enable two-step verification, set suitable project permissions and retention periods, and choose export approval and your own vault key where needed. Without configured retention periods, results and reversal keys are not automatically deleted. Pseudonyms and context still need human review.

Based on the official requirements

This explanation connects the requirements to our document features. Read more about processing and practical limits on our security page.

Assess it together

A question about your security requirements?

Share your intended document process or supplier assessment questions. We can discuss which measures fit.

Email info@anonimize.eu