European Compliance by Design

Principle

Regulation as an architectural consideration

Most regulatory obligations end up as properties of a system: where data is stored, who can actually reach (access) it, what is logged & where it is logged, how fast a failure is detected/located and how a component can be replaced. These properties are cheap to establish while the architecture is still being shaped by a qualified architect. Added after go-live (which sadly is still common), they tend to become workarounds in many cases: an extra copy of data to support an audit - in worst case from PROD, a manual approval step outside the system managed in "some Excel File", a log that exists somewhere but nobody can query it.

Treating regulation as an architectural input does not mean architects interpret the law, and they shouldn't. It means legal and compliance analysis work with the same requirements and decisions as functional and non-functional needs, and that the resulting design can show how each obligation/rule is addressed. In the end this is a team effort, as no technical architect will ever be a fully trained compliance expert... The good ones know a lot, but this is where it ends. It follows the same sequence as my architecture approach:

1. Understand the applicable obligations at a high level first. Establish which instruments apply, in which role (controller or processor, provider or deployer, manufacturer, essential or important entity, financial entity) and for which processes and data. This is a legal question first; the architect needs the outcome, not a self-made legal interpretation.
2. Translate obligations into technical requirements. Turn obligations into concrete, testable technical requirements: retention periods, access boundaries, logging scope, recovery objectives, documentation that must be producible on request. Important is that those are actually tested not just implemented and documented.
3. Make decisions and trade-offs explicit. Regulatory requirements compete with cost, usability and delivery speed. Record the options, the decision, the remaining risk and who accepted it. A known gap with an owner and a remediation plan is very different from a gap nobody noticed. Of course, documenting a decision does not make a legal obligation optional.
4. Implement governance and technical controls. Controls belong in the platform and the delivery process: identity and access, encryption, policy enforcement, segregation of environments, review gates. A policy document alone does not restrict access.
5. Verify and keep operational accountability. Test that controls actually work (very important), monitor that they keep working, and assign owners in operations. Compliance is a property of a running system and the organisation around it, not of the design document sitting in SharePoint.

Good architecture makes compliance demonstrable and less fragile. It does not guarantee it, however: organisational measures, contracts, processes and legal assessments remain necessary. NIS2 is a good example because it puts explicit duties on management bodies. The CISO and architect can build the controls, but management cannot simply delegate accountability and forget about it.

GDPR

GDPR: privacy and data governance

Scope Regulation (EU) 2016/679. Applies to the processing of personal data by controllers and processors.

The GDPR is often treated as a matter of consent forms and privacy statements. I personally think we can and should improve here as architects. For architects, its weight lies elsewhere: it requires that technical and organisational measures are chosen at the time the means of processing are determined - ideally at design phase. In practice, that is the moment the data model, the integrations and the platform are designed.

What the regulation sets out

• Principles for all processing (Art. 5), including purpose limitation, data minimisation, storage limitation, and integrity and confidentiality. The controller must be able to demonstrate compliance (accountability, Art. 5(2)).
• A lawful basis for each processing operation (Art. 6). When data is reused for a new purpose without fresh consent or a qualifying basis in EU or Member State law, assess whether the new purpose is compatible with the original one (Art. 6(4)). Small practical example: if you want Copilot to scan incoming emails, assess whether that processing fits the documented purpose and lawful basis. “The data was already in Outlook” is not the assessment.
• Data protection by design and by default (Art. 25) and security of processing appropriate to the risk (Art. 32).
• Records of processing activities (Art. 30), a data protection impact assessment (DPIA) where processing is likely to result in a high risk (Art. 35), contracts with processors (Art. 28) and rules for transfers outside the EEA (Chapter V).

What this means for the architecture

• Data flows. Map where personal data enters, where it is copied or enriched and where it leaves. Include integrations, analytics platforms, logs, backups and test environments. The main CRM is rarely the surprise; the forgotten export or old test copy usually is.
• Minimisation in the data model. Collect only the attributes a process needs, and use anonymised or pseudonymised data outside production. Copying production data into test environments can conflict with purpose limitation unless the use has been assessed and appropriate safeguards are in place.
• Purpose at the boundaries. Tie integrations and datasets to documented purposes. Feeding existing data into reporting, a data platform or an AI model may change how and why it is processed. Check that deliberately instead of treating every new integration as an automatic extension of the old purpose.
• Access control. Apply least privilege through roles, ownership and field-level restrictions (for example Dataverse security roles, business units and column security). And please review privileged and service accounts regularly; “nobody knows what this account does” is not a security model.
• Retention and deletion. Design retention and deletion across integrations and copies. Deleting a contact from the CRM while the same data remains in a data lake, an export and three test environments does not solve much.
• Enterprise AI and personal data. Prompts, retrieved documents and generated output can all contain personal data. Grounding sources should respect existing permissions. Using internal data with AI constitutes processing and requires an assessment of its purpose, lawful basis, compatibility and safeguards. See the hidden GDPR problem in enterprise AI.

NIS2

NIS2: cybersecurity and architecture

Scope Directive (EU) 2022/2555. Applies through national law to essential and important entities in the sectors it lists.

NIS2 is not a shopping list where you buy MFA, a SIEM and a backup product and call the organisation compliant. It asks organisations in scope to manage cybersecurity risk with appropriate and proportionate measures, and it puts explicit responsibility on management. Because NIS2 is a directive, the national implementation still matters; scope, supervision and details can differ between member states.

What the regulation sets out

• Management bodies approve the cybersecurity risk-management measures, oversee their implementation, can be held liable for infringements and must follow training (Art. 20). Depending on national implementation, members of management may face personal liability. Whether directors’ and officers’ insurance covers that exposure depends on the policy and applicable law, so it should be checked rather than assumed.
• Technical, operational and organisational measures based on an all-hazards approach (Art. 21). The minimum list covers risk analysis and security policies, incident handling, business continuity including backup and disaster recovery, supply-chain security, security in acquisition, development and maintenance including vulnerability handling, assessment of effectiveness, cyber hygiene and training, cryptography, access control and asset management, and multi-factor authentication where appropriate.
• Reporting of significant incidents: an early warning within 24 hours, an incident notification within 72 hours and a final report no later than one month after that incident notification (Art. 23). If the incident is still ongoing, a progress report is due at that point and the final report follows within one month after the incident has been handled.

What this means for the architecture

• Security by design. Model threats and trust boundaries while the design can still change: network isolation, private connectivity, separated environments, encryption and secrets management. Retrofitting those after go-live is possible, but it is rarely cheap or elegant.
• Identity as the control plane. Centralise identity (for example Microsoft Entra ID), enforce conditional access and MFA, use just-in-time privileged access, and prefer managed identities over stored secrets. Service principals and technical users need the same attention as human accounts; sometimes more, because nobody notices them for years.
• Logging and monitoring. Decide what must be logged, where it is retained and, crucially, who reviews it. Reporting deadlines are measured in hours. A log that exists somewhere but cannot help reconstruct an incident quickly is mostly expensive storage.
• Technical resilience. Derive recovery objectives from business impact and actually test restores. “We have backups” and “we can recover the service within four hours” are two very different statements.
• Supply chain. Make dependencies on SaaS platforms, integrators and libraries visible. Then connect contractual promises to technical controls such as scoped access and monitoring of supplier activity. Outsourcing a service does not outsource the risk.
• Security governance. Record security-relevant decisions and accepted risks with an owner, and measure whether controls work. This gives management evidence instead of another green dashboard built on assumptions.

One more time because this gets confused surprisingly often: implementing MFA or a SIEM does not by itself establish NIS2 compliance. The measures need to fit the risks, be governed properly and actually work in practice.

During an active security incident, the first priority must be to stop the damage. If a critical vulnerability is being exploited, I want the engineers isolating affected systems, closing the vulnerability and restoring control. I certainly don’t want to pull the people fixing the problem into meetings because someone needs a regulatory report—sorry for that, but that is the reality.

Reporting to authorities is important, but the immediate technical response comes first. Once the most urgent containment measures are underway, the organisation needs to address its notification obligations. That doesn’t mean reporting can be postponed indefinitely. Legal deadlines still apply, and someone needs to take responsibility for meeting them without getting in the engineers’ way. This is important because the IT infrastructure is bound to the existence of the organisation. The reporting is not.

In my view, this is where compliance processes need to be practical. During an emergency, stopping the attack must take priority over paperwork. A reporting process that interferes with containment is badly designed.

EU AI Act

EU AI Act: AI governance and system design

Scope Regulation (EU) 2024/1689. Obligations depend on the role (provider, deployer, importer, distributor) and on the risk category of the AI system.

The AI Act regulates AI systems according to risk. That sounds simple until a project team has to decide what the system is actually meant to do, which legal role the organisation has, what data the model uses and who can intervene when the output is wrong. Those are legal questions, but they are also architecture questions from day one.

What the regulation sets out

• The original prohibited practices (Art. 5) and the AI literacy obligation (Art. 4) apply since 2 February 2025. Newly added prohibitions in Art. 5(1), points (ba) and (bb), and Art. 5(1a) and (1b) apply from 2 December 2026. Obligations for general-purpose AI models apply since 2 August 2025; transparency obligations for certain AI systems, such as disclosure of AI interaction and marking of generated content (Art. 50), since 2 August 2026.
• High-risk classification follows from Art. 6 together with Annex I (safety components of regulated products) and Annex III (listed use cases such as employment, credit scoring and access to essential services).
• High-risk systems require risk management (Art. 9), data governance (Art. 10), technical documentation (Art. 11), automatic record-keeping (Art. 12), transparency towards deployers (Art. 13), human oversight (Art. 14) and accuracy, robustness and cybersecurity (Art. 15). Deployers have their own obligations (Art. 26), including human oversight and monitoring of operation.
• The 2026 Digital Omnibus amendment postponed the application of the high-risk requirements to 2 December 2027 for Annex III systems and 2 August 2028 for Annex I systems. The requirements themselves were not removed.

What this means for the architecture

• Risk classification as a design input. Classify the intended purpose before choosing models and platforms, not two weeks before go-live. A changed purpose or substantial modification can change the role and obligations (Art. 25), so classification belongs in architecture governance and not only in a procurement checklist. See what qualifies as high-risk AI.
• Data governance. Keep the lineage of training, evaluation and grounding data, including quality and known limitations. If personal data is involved, GDPR applies alongside the AI Act. One regulation does not politely wait while you deal with the other.
• Human oversight. Build oversight into the user experience: show the basis of a recommendation, allow people to correct or stop the process, and avoid interfaces that push users towards automatic acceptance. A sentence in a policy saying “a human remains responsible” does not create meaningful oversight.
• Documentation and traceability. Log inputs, model and prompt versions, configuration and outputs well enough to reconstruct a decision. Version the technical documentation with the system; documentation for version 1.2 is not very useful when production runs version 3.7.
• Monitoring. Monitor quality, drift and incidents in operation and feed the findings back into risk management. For providers of high-risk AI systems this is a formal post-market monitoring obligation (Art. 72), but even outside that case it is simply sensible engineering.
• Integration into enterprise systems. AI components inherit permissions, data boundaries and failure modes from the systems around them. Decide what happens when the model is unavailable, slow or confidently wrong. A core business process should not collapse because an external model endpoint has a bad afternoon.

For the time being, avoiding AI systems that could qualify as high-risk can be sensible practical advice. The legal position is still developing: the EU Omnibus changes the rules and the timelines continue to shift. Given the administrative burden and architectural effort, I would only choose a high-risk AI system when the business case is clearly defined and measurable. The expected value needs to justify the additional compliance and IT effort, both now and throughout the system’s operational life.

DORA · CRA

DORA and CRA: operational resilience and software security

Scope Two separate regulations with different addressees. Both affect how dependencies and software are managed over their lifecycle.

DORA and the Cyber Resilience Act are often mentioned in the same compliance conversation, but please do not treat them as interchangeable. DORA is about the operational resilience of financial entities, including disruption caused by technology providers. The CRA is about the cybersecurity of products with digital elements and the responsibilities of their manufacturers before and after market release.

The revised Product Liability Directive adds a separate dimension: software is explicitly a product, so a defect can ground a liability claim. See whether your software is a product or a service.

Approach

Connecting regulation to architecture decisions

None of these regulations hands you a ready-made architecture diagram (sadly). They describe outcomes: data used for a known purpose, risks that are managed, incidents that are detected, systems that recover, software that is maintained and decisions that can be explained. Turning those outcomes into something a team can actually build and operate is architecture work.

In practice, good architecture balances four inputs that rarely point in exactly the same direction:

• Business requirements: what the organisation needs the system to do and, equally important, why.
• Technical feasibility: what the platforms and team can realistically deliver and maintain, not what looked good in a vendor demo.
• Operational constraints: budgets, skills, the existing landscape and service levels. These do not disappear because an architecture diagram looks clean.
• Applicable regulatory obligations: what must be demonstrably true of the system and its operation, with evidence rather than assumptions.

My architecture approach shows how I move these inputs from context and requirements through patterns, technology choices and guardrails into delivery and operations. The feedback loop matters: obligations do not disappear after go-live, even if the project team does. At the same time, stay practical. Trying to resolve every small compliance detail before moving forward can stall an IT project. In my view, the key is to meet the obligations while keeping delivery workable. That balance is the sweet spot every architect should aim for.