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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
24 hours
Early warning
An initial warning to the competent authority.
72 hours
Incident notification
An initial assessment of severity, impact and available indicators.
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.