ENS, NIS2, DORA, AI Act, GDPR, eIDAS, Data Act, ISO 27001, NIST, CIS. For many technical teams, the regulatory map begins to look like an endless list of acronyms that always arrives late to the table: when there’s a tender, an audit, a financial client, a pending certification, or a security incident.
The common mistake is treating each framework as if it were a separate project. One team deploys ENS, another prepares ISO 27001, legal reviews GDPR, security discusses NIS2, product team starts to review the AI Act, and procurement asks about vendors. The result is usually a pile of documents, duplicated controls, and evidence scattered across emails, tickets, spreadsheets, and tools that don’t communicate with each other.
For a tech organization, the most useful way to view compliance is not to start from the standards, but from the actual architecture: what services are provided, what data is processed, what infrastructure is used, which third parties are involved, which clients depend on it, and what impact a failure, data breach, or poorly governed automation would have.
From the legal matrix to the technical service map
Regulatory applicability rarely depends on a single label. A company can be simultaneously a cloud provider, MSP, software developer, data controller, financial institution provider, AI platform operator, and contractor for a public sector contract. Each role carries different obligations.
The National Security Scheme in Spain is regulated by Royal Decree 311/2022 and affects systems that handle information or services within electronic administration and their providers. NIS2, Directive (EU) 2022/2555, raises the common level of cybersecurity across the European Union for essential and important entities. DORA, Regulation (EU) 2022/2554, focuses on digital operational resilience in the financial sector and TIC risk management. The AI Regulation, Regulation (EU) 2024/1689, adopts a risk-based approach for AI systems.
On top of these, horizontal standards cover privacy, digital identity, data, and re-use. GDPR governs personal data processing; eIDAS covers electronic identification and trust services; the Data Act sets rules for data access and usage, and the Data Governance Act establishes mechanisms for governance and data sharing within the EU.
Practically, this means that the inventory of services matters as much as the inventory of assets. Knowing how many servers, containers, buckets, clusters, or databases exist isn’t enough. You need to know which service each asset supports, what data it processes, which customer uses it, what SLA applies, which provider is involved, and what contractual or regulatory obligations attach to it.
A CRM with personal data is governed differently from an AI scoring platform. A backup for a municipality doesn’t share the same context as an internal analytics system. A cloud provider serving a financial institution bears a different level of exposure than a corporate website. The architecture ultimately explains how the standard applies.
The common core: identity, logs, patches, evidence, and governance
Though each regulatory framework has its own language, many requirements lead to similar controls: risk management, governance, access control, strong authentication, segregation of duties, asset inventories, encryption, vulnerability management, monitoring, incident response, continuity, vendors, training, and auditing.
For technical teams, this allows building a common foundation. Deploying separate evidence systems for ENS, ISO 27001, DORA, and NIS2 makes little sense if they all ask for the same points: who accesses with what privileges, what changes have been made, which vulnerabilities are open, when was the backup tested, what occurred during an incident, and who approved an exception.
Modern compliance increasingly resembles platform engineering. Identity and Access Management (IAM), Multi-Factor Authentication (MFA), Privileged Access Management (PAM), Security Information and Event Management (SIEM), Endpoint Detection and Response (EDR), Configuration Management Database (CMDB), ticketing, vulnerability scanners, CI/CD pipelines, Git repositories, cloud inventories, secrets management, backups, and GRC tools must be part of the same conversation.
A simple example: vulnerability management. In a mature organization, it shouldn’t just be exporting a monthly PDF for audit purposes. It should have an up-to-date inventory, severity per service, technical owner, remediation SLA, approved exceptions, traceability in tickets, and closing evidence. The same workflow applies across ENS, NIS2, ISO 27001, DORA, or contractual client requirements.
The same goes for logs. It’s not enough to store events; you must define what is logged, how long it’s retained, ensure integrity, control access, correlate alerts, and reconstruct timelines after incidents. For security, it’s daily operations; for legal and compliance, it’s probative capacity.
AI adds an extra challenge. The AI Act requires considering risk, intended use, documentation, human oversight, data, traceability, and lifecycle management. Technically, this means shifting from “we integrated a model” to “we know which model we use, with what data, for what purpose, under what controls, with what metrics, what limitations, and who is responsible if it fails.”
Compliance as code: fewer folders, more operations
The next step is transforming compliance into continuously verifiable controls. Not everything can be automated, but many evidence points can be generated through operations.
A MFA policy is ineffective if the identity console shows privileged accounts without second factors. A backup process is pointless if there’s no proof of restoration. Encryption commitments fall short if buckets are public, volumes unencrypted, or secrets stored in repositories. A vendor matrix isn’t useful if it isn’t linked to contracts, risk assessments, subprocessors, and exit plans.
Compliance as code involves bringing compliance closer to where technology is deployed and operated: policies in repositories, controls in pipelines, infrastructure as code validations, insecure configuration detection, automatic evidence collection, and dashboards per service. It doesn’t replace legal analysis or CISO judgment but reduces the gap between what the company claims to do and what its systems actually do.
It also changes the legal-technical relationship. A tech lawyer can no longer work with clauses alone. They need to understand cloud dependencies, data handling, provider roles, activity logs, AI architecture, incidents, and supply chain. Conversely, the tech team must see regulation not as a burden but as good engineering and security practices made enforceable.
The challenge for 2026 isn’t memorizing all acronyms. It’s building a model that enables quick answers to specific questions: for that service, with those data, clients, and vendors, what risks are present, what controls cover them, and what evidence can be shown tomorrow.
Organizations that succeed will not have thirty compliance programs running in parallel. Instead, they will have a solid common foundation and specific layers tailored to service, sector, and risk. That’s the difference between just passing an audit and operating within a prepared, regulated environment architecture.
Frequently Asked Questions
What should a technical team do first with so many standards?
Map services and dependencies. Before focusing on controls, it’s important to understand which systems support each service, what data they handle, who their clients are, and which third parties are involved.
Does ISO 27001 cover ENS, NIS2, or DORA?
It’s very helpful as a security management foundation but isn’t a substitute for the specific analysis of each framework. ENS, NIS2, and DORA have their own obligations that must be explicitly mapped.
What does compliance as code mean?
It means automating or semi-automating compliance controls within technical operations: pipelines, infrastructure as code, inventories, monitoring, access management, and evidence collection from real systems.
How does the AI Act impact tech teams?
It requires better documentation and governance of AI systems, especially high-risk ones. This includes purpose, data, human oversight, traceability, change management, risk assessment, and responsibilities.
Source: Abogados Contratos
