01
October 15, 2026
DORA: Will your recovery plan work when several systems fail?
A documented recovery plan does not guarantee that a critical business function can resume. Here is how to test dependencies end to end.
03 SECTION / CYBERCORIA
Regulation
Connect official texts, governance obligations and the reality of the information system without turning compliance into a slogan.
STARTING POINT
NIS2, DORA, GDPR, ANSSI/CNIL/ENISA guidance and the relationship between requirements, assets and evidence.
We separate what texts require, what authorities recommend and what mapping or technical controls can genuinely help demonstrate.
Questions we are trying to answer
- What does the text actually require?
- Which operational evidence needs to be retained?
- Where does mapping help?
- Which limitations should remain visible?
01 / Regulation
Start with the text, not with a product
Cybercoria separates three levels: what the legal text requires, what an authority or agency recommends, and what an organisation may choose as an operational means. This avoids turning a technical feature into a regulatory obligation that does not exist.
02 / Regulation
A requirement becomes operational when it meets the real system
Asset management, continuity, supply chain, data, access and evidence do not live in isolated documents. The analyses show which system objects and relationships can help address a requirement without claiming that mapping alone proves compliance.
03 / Regulation
Evidence remains distinct from the repository
A map can show a dependency; it cannot prove that a backup was restored, an access review took place or an incident was handled within a required timeframe. Separating structure, controls and evidence is a recurring editorial principle in this section.
ANALYSES
11 publications
02
October 9, 2026
Anonymised data: can re-identification risk change after an export?
Removing names does not necessarily anonymise a dataset. Before sharing, assess what the recipient can isolate, link and infer.
03
September 21, 2026
Generative AI: can you trace where a data point came from after ingestion?
Between a web page and an AI model, data can be copied, filtered, transformed and incorporated into multiple artefacts. Provenance helps reconstruct that path.
04
September 17, 2026
DPIA: why GDPR analysis should start from the real system architecture
A DPIA can be thoroughly documented while still describing the system that actually processes the data imperfectly. Connecting processing, flows, applications, storage and dependencies helps confront GDPR analysis with the deployed architecture.
05
September 16, 2026
DORA: what the first year of major incidents reveals about your architecture
DORA's first annual incident overview moves the discussion beyond regulatory theory: real incidents highlight shared dependencies, critical functions and recurring root causes.
06
September 16, 2026
CRA: is your cloud backend part of the product you must secure?
The CRA does not necessarily stop at installed software or hardware: some remote data processing solutions can form part of a product with digital elements.
07
August 31, 2026
CRA: prepare vulnerability and incident reporting before 11 September
From 11 September 2026, specific Cyber Resilience Act reporting obligations become applicable. For manufacturers, the operational challenge is to quickly connect product, version, vulnerability or incident, exploitation evidence, remediation and timeline.
08
August 28, 2026
DORA: prepare the first hours of a major ICT incident
The first DORA report on major ICT incidents highlights an operational requirement: being able to retrieve the data connecting incidents, functions, services, third parties and impacts immediately.
09
August 25, 2026
DORA: build the ICT third-party register from the real information system
The DORA register of information is not a simple vendor list. It links contracts, ICT services, functions, providers, subcontractors and assessments; building it from governed IS data reduces inconsistencies.
10
August 24, 2026
NIS2 Article 21: what information system mapping can actually help demonstrate
Article 21 of NIS2 requires a risk-management approach covering incidents, continuity, supply-chain security, access and asset management. Where does information system mapping genuinely help?
11
August 24, 2026
GDPR: information system mapping and records of processing are different — but complementary
The GDPR record organises processing activities by purpose. Information system mapping describes applications, flows and infrastructure. Connecting the two can improve governance without confusing their roles.
PUBLICATION CRITERION
A page is published only when it contributes information, a method, a synthesis or a verifiable angle that justifies its existence beyond a search-ranking objective.