I have spent enough time inside EU-regulated organisations to know that the tools they use for governance, risk, and compliance were not built for them. They were built for US enterprises managing SOX, HIPAA, and SOC 2, then localised with a European language pack and a GDPR module bolted on as an afterthought. The result is a category of software that treats EU regulatory complexity as an edge case rather than the core design constraint.
FortisEU exists because I believe that is wrong. The EU regulatory landscape — NIS2, DORA, the AI Act, GDPR enforcement evolution, the Cyber Resilience Act, sector-specific implementing acts across 27 Member States — is not a variation on the US compliance model. It is a fundamentally different operating environment that requires purpose-built tooling. And the organisations navigating this environment deserve a platform that was designed from the ground up for their reality, not adapted from someone else's.
This post explains the thesis behind FortisEU: why the market gap exists, why compliance must be continuous rather than periodic, why EU sovereignty is a hard requirement, and why a platform approach matters more than point solutions.
The Market Gap: US-Centric GRC Does Not Serve EU Entities
Walk into any enterprise GRC vendor's demo and ask about NIS2 transposition tracking across multiple EU jurisdictions. Ask how the platform handles the interaction between DORA's ICT risk management framework and NIS2's security measures when both apply to the same entity. Ask about AI Act risk classification workflows that account for the Regulation's phased obligation activation dates. Ask about GDPR enforcement trend analysis that considers the divergent approaches of 30+ data protection authorities.
You will get one of two responses. Either the vendor will show you a generic framework mapping tool that treats every regulation as a flat checklist — which misses the structural relationships between EU regulations — or they will acknowledge that their EU coverage is "on the roadmap" and offer to discuss your requirements with their product team.
This is not a criticism of these vendors. They built excellent products for their primary market: US enterprises managing a regulatory environment that is, relative to the EU, structurally simpler. The US has fewer overlapping federal regulations, limited state-level variation in cybersecurity requirements, and a compliance culture that prioritises certification (SOC 2, FedRAMP) over continuous operational evidence.
The EU environment is different in ways that break US-centric GRC architecture.
Multi-jurisdictional complexity. A company operating across five EU Member States must navigate five different NIS2 transpositions, potentially with different entity classification criteria, different supervisory authorities, and different enforcement approaches. This is not a localisation problem — it is a structural complexity that requires the platform to model jurisdictional variation as a first-class concept.
Regulatory interdependence. NIS2, DORA, and the AI Act are not independent regulations. They share conceptual foundations (risk-based approach, proportionality) but impose overlapping and sometimes conflicting requirements. A financial entity subject to both NIS2 and DORA must understand where DORA's requirements satisfy NIS2 through the lex specialis principle (Article 4 of NIS2) and where additional NIS2-specific measures are needed. A platform that models each regulation as a separate checklist cannot represent these relationships.
Continuous evidence requirements. EU regulations increasingly require ongoing evidence of control effectiveness, not point-in-time certification. NIS2 Article 21 requires "appropriate and proportionate" security measures that are maintained and updated. DORA Article 6(5) requires the ICT risk management framework to be "updated on the basis of lessons derived from implementation and monitoring." The AI Act requires ongoing monitoring and updating of high-risk AI systems. This continuous evidence model demands a platform that tracks control effectiveness over time, not just control implementation at a moment.
EU sovereignty as a constraint. For regulated EU entities, the sovereignty question is not philosophical — it is operational. Where is compliance data stored? Which jurisdiction's laws govern access to that data? Can a foreign government compel disclosure of your risk assessments, your control evidence, your incident reports? These are questions that EU regulators ask and that US-headquartered GRC vendors cannot always answer satisfactorily.
The Thesis: Compliance Must Be Continuous
The traditional compliance model operates on an annual cycle: assess controls, identify gaps, remediate, produce evidence, present to auditors, receive certification, repeat next year. This model worked when regulatory requirements were stable, threat landscapes evolved slowly, and auditors accepted point-in-time evidence.
None of those conditions hold today.
Regulatory requirements change continuously. NIS2 implementing acts, DORA regulatory technical standards, AI Act delegated acts, GDPR enforcement guidance updates, ENISA threat landscape reports, national transposition variations — the regulatory input to compliance programmes changes on a weekly basis. An annual compliance cycle cannot incorporate these changes without creating an ever-growing backlog of regulatory updates that accumulates between cycles.
Threat landscapes evolve daily. A control that was effective against last quarter's threat landscape may be ineffective against this quarter's. Vulnerability disclosures, attack technique evolution, and supply chain compromises create a continuously shifting baseline that static compliance snapshots cannot track. NIS2 Article 21(2)(e) explicitly requires assessment of "the effectiveness of cybersecurity risk-management measures" — effectiveness that can only be measured through continuous monitoring, not annual review.
Evidence decays. A penetration test completed twelve months ago tells you what your perimeter looked like twelve months ago. A risk assessment conducted last quarter reflects last quarter's risk landscape. An access review performed in January does not account for access changes made in February. Every piece of compliance evidence has a shelf life, and most shelf lives are shorter than the annual cycle that produced them.
The continuous compliance model — which we call Continuous Control Security — operates on a fundamentally different premise: compliance is a continuous operational state, not a periodic project outcome. Controls are validated continuously. Evidence is collected and refreshed on risk-appropriate cadences. Regulatory changes are incorporated as they occur. Compliance posture is measured in real time, not reconstructed annually.
This is not a marginal improvement to the annual model. It is a structural change in how compliance operates. And it requires tooling that is designed from the ground up for continuous operation — not annual-cycle software with a "continuous monitoring" checkbox added to the feature list.
EU Sovereignty: A Requirement, Not a Feature
When I say FortisEU is EU-sovereign, I do not mean that we have a data centre in the EU. I mean that sovereignty is an architectural constraint that informs every technology decision we make.
Infrastructure. FortisEU runs on Scaleway, a French cloud provider subject to French and EU law. Not AWS with an EU region. Not Azure with EU data residency. Scaleway, headquartered in Paris, subject exclusively to EU jurisdiction. This matters because the US CLOUD Act and FISA Section 702 create legal mechanisms for US government access to data held by US-headquartered companies regardless of where that data is physically stored. For EU-regulated entities whose compliance data includes risk assessments, incident reports, and control evidence, this jurisdictional exposure is not acceptable.
AI processing. FortisEU uses Mistral AI, a French AI company, for all AI-assisted capabilities. Not OpenAI. Not Anthropic (though I have deep respect for their work). Mistral, headquartered in Paris, processing data under French and EU law. When a compliance team uses AI to analyse regulatory requirements, draft control descriptions, or map evidence to frameworks, the data involved is sensitive enough to warrant sovereign processing.
Authentication. Our authentication broker is the single remaining non-EU dependency in our architecture, and it is architecturally swappable to a self-hosted EU alternative. We made this trade-off consciously — the authentication broker does not process compliance data, and the architectural isolation ensures that swapping it does not require rebuilding the platform.
Why this matters operationally. Sovereignty is not a marketing claim. It is the answer to a specific question that every CISO and DPO at an EU-regulated entity must be able to answer: "If a foreign government requests access to our compliance data, what is our exposure?" With FortisEU, the answer is: none, because there is no legal mechanism for a non-EU government to compel access to data held by EU companies on EU infrastructure processed by EU AI providers.
For entities subject to NIS2, DORA, and GDPR, this is not a premium feature. It is a baseline requirement. The fact that most GRC vendors cannot make this claim tells you something about how the category was built and for whom.
The Platform Approach: Why Point Solutions Fail
The alternative to a platform is a collection of point solutions: one tool for compliance management, another for risk assessment, a third for vendor risk, a fourth for incident management, a fifth for policy management, and a spreadsheet to reconcile them all.
This approach fails at scale for three reasons.
Data fragmentation. When compliance evidence lives in one system, risk scores live in another, and vendor assessments live in a third, no single system has the complete picture. Answering "what is our risk exposure to this vendor, considering both our compliance dependencies and our technical dependencies?" requires manually correlating data across systems. This correlation is where errors occur, insights are missed, and reporting takes days instead of minutes.
Inconsistent risk models. Each point solution implements its own risk methodology. The risk score in your compliance tool is not comparable to the risk score in your vendor management tool. The control taxonomy in your GRC platform does not map cleanly to the control categories in your security monitoring platform. These inconsistencies mean that executive reports require manual reconciliation, and the reconciled output reflects the analyst's interpretation rather than a coherent model.
Integration maintenance burden. Point solutions must be integrated to exchange data. These integrations are fragile, require ongoing maintenance, and break when any connected system updates its API. The integration maintenance burden grows quadratically with the number of connected systems. An organisation with five point solutions has up to ten pairwise integrations to maintain. Each integration is a potential failure point that can silently degrade data quality.
FortisEU is built as a single platform where compliance, risk, vendor management, incident response, policy governance, and regulatory intelligence share a common data model, a common risk methodology, and a common evidence base. When a vendor incident occurs, the platform can immediately surface the compliance impact, the affected controls, the risk exposure, and the regulatory reporting obligations — because all of that data lives in the same system with the same relationships.
This is not a technical achievement. It is an architectural decision. We chose to build one coherent system rather than acquire and integrate separate systems. That decision has trade-offs — we build more ourselves, we move more slowly in any single domain, we cannot claim "best of breed" in every category. But for EU-regulated entities that need their governance, risk, and compliance operations to function as one coherent system rather than a collection of loosely coupled tools, the platform approach is the right architecture.
What We Are Building Toward
FortisEU is not finished. No platform of this scope is ever finished. But the direction is clear, and it has been clear from the beginning.
We are building toward a state where an EU-regulated entity can manage its entire compliance and risk posture — across NIS2, DORA, GDPR, the AI Act, and sector-specific regulations — in a single sovereign platform that operates continuously, not periodically. Where controls are validated against live evidence, not annual attestations. Where regulatory changes are incorporated automatically, not through manual gap analysis. Where vendor risk is monitored continuously, not assessed annually. Where executive reports reflect current operational reality, not last quarter's snapshot.
We are building this for the CISO who is accountable under NIS2 Article 20 and needs to demonstrate continuous compliance to a board that asks hard questions. For the compliance team that is drowning in spreadsheets and manual evidence collection across multiple regulatory frameworks. For the risk manager who knows that their risk model is only as good as the data that feeds it. For the DPO who needs to demonstrate GDPR accountability with evidence, not assertions.
This is the Continuous Control Security category. It is not a slogan. It is a system architecture — one where governance controls and technical exposure operate as a single continuous intelligence system rather than parallel, disconnected workflows.
We are building it because no one else is. And because the organisations that need it cannot wait for US-centric GRC vendors to eventually, maybe, get around to treating the EU as a first-class market.
Key Takeaways
- US-centric GRC tools treat EU regulatory complexity as a localisation problem — but multi-jurisdictional NIS2 transposition, DORA/NIS2 lex specialis interactions, and continuous evidence requirements demand purpose-built architecture, not bolted-on EU modules.
- Compliance must be continuous because regulatory requirements change weekly, evidence decays faster than annual cycles can refresh it, and NIS2/DORA explicitly require ongoing effectiveness assessment — the annual compliance project model is structurally inadequate.
- EU sovereignty is an architectural constraint, not a feature flag — FortisEU runs on Scaleway (French cloud), uses Mistral AI (French AI), and ensures that no non-EU legal mechanism can compel access to customer compliance data.
- The platform approach eliminates data fragmentation, inconsistent risk models, and integration maintenance burden that make point-solution portfolios operationally brittle — a single data model with shared risk methodology and common evidence base is the right architecture for continuous compliance.
- FortisEU exists because the EU-regulated enterprise deserves tooling built for its reality, not adapted from someone else's — and that tooling must treat sovereignty, regulatory interdependence, and continuous evidence as core design constraints rather than roadmap items.