1. The core thesis: compliance belongs inside the architecture
Most software teams still treat legal review as a downstream activity: product and engineering decide what to build, developers implement it, security tests it, and only shortly before release does legal assess privacy notices, contracts, regulatory exposure and residual risk. That sequence is expensive because many legal obligations are not documentary obligations. They are architecture-shaping constraints.
Data minimisation affects event schemas, retention rules and analytics design. Purpose limitation can affect service boundaries and data access paths. Security obligations affect authentication, secret management, logging, dependency governance and incident response. Portability duties can affect database abstractions and export formats. Accessibility can affect design systems and test automation. AI governance can affect dataset lineage, model evaluation, human oversight, logging and post-market monitoring. Financial-sector resilience rules can affect environment separation, change approval and operational testing.
The right model is therefore not “engineering first, compliance later”. It is a single product assurance pipeline in which product, engineering, security and legal requirements are decomposed into controls and evidence from the beginning.
Legal-by-design is not legal veto-by-design. Its purpose is to convert applicable law into explicit design constraints, acceptance criteria, evidence requirements and escalation points as early as possible. The result is less architectural rework, fewer late-stage blockers and faster enterprise due diligence.
The engineering principle behind the legal principle
NIST's Secure Software Development Framework treats security practices as activities to be integrated into the software development lifecycle rather than added after development. Its stable SSDF 1.1 explicitly includes documenting security requirements and tracking software security requirements, risks and design decisions. NIST released SSDF 1.2 as a public draft in December 2025, further developing secure and reliable software lifecycle practices. The direction is clear: requirements, decisions and evidence should travel together through the lifecycle.
That engineering model maps naturally onto modern regulation. GDPR Article 25 requires data protection by design and by default. NIS2 requires security in acquisition, development and maintenance and expressly addresses supply-chain security. The AI Act defines lifecycle-based risk management, documentation and monitoring obligations for regulated AI systems. DORA requires documented ICT risk management and controlled changes in the financial sector. The Data Act places portability and switching requirements directly into the technical design of data processing services.
2. A repeatable engineering pipeline for SaaS and app development
A traceable architecture starts before the first production code is written. The goal is to create a chain in which every material decision has an owner, every control has a test or review method, and every release can be traced back to the source, configuration and approval state that produced it.
Product and system requirements
Define functional requirements and non-functional requirements: security, privacy, availability, latency, resilience, accessibility, auditability, portability, data residency, retention and recovery objectives. Legal counsel helps determine which of these are mandatory, contractual, sectoral or risk-based.
Architecture description
Maintain system-context, container/component and deployment views; trust boundaries; data-flow diagrams; identity flows; external dependencies; and data stores. The objective is not diagram volume, but a shared and current representation of where obligations attach.
Architecture Decision Records
Use ADRs for architecturally significant decisions: tenancy model, encryption strategy, region selection, event architecture, API exposure, third-party AI providers, observability, key management, data deletion and portability. Each ADR should record context, decision, alternatives, consequences, owner and status.
Contract-first interfaces
Version APIs and events through machine-readable contracts such as OpenAPI or AsyncAPI where appropriate. Schema evolution, backward compatibility and deprecation should be governed. This reduces integration ambiguity and creates a stable point for privacy, security and portability review.
Infrastructure as Code
Networks, cloud resources, IAM policies, storage, logging and environment configuration should be reproducible from version-controlled definitions. Manual production configuration should be exceptional, documented and reviewable.
Controlled delivery
Use protected branches, peer review, automated testing, dependency scanning, secrets scanning, SAST, infrastructure scanning and controlled deployment workflows. Production releases should originate from known commits through known build instructions.
Traceability requires immutable history, not perfect foresight
A serious architecture is not one that never changes. It is one that can explain why it changed. AWS guidance on ADRs recommends preserving accepted decisions and superseding them with new records rather than silently rewriting history. This is especially valuable where a design choice was influenced by a regulatory interpretation, a data-protection assessment, a threat model or a customer commitment.
That history turns architecture into institutional memory. It also makes later legal impact analysis substantially faster: counsel does not have to reconstruct months of technical reasoning from tickets and conversations.
3. Build an evidence chain, not a compliance folder
The most useful architecture for regulated software is an evidence architecture. A policy document that says “we encrypt data” is weak evidence. A stronger chain identifies the legal or contractual requirement, the architectural decision that implements it, the configuration or code enforcing it, the automated verification proving it, and the release artifact in which the control is present.
This chain should be bidirectional. From a regulatory requirement, the team should be able to identify the implemented controls. From a production control, the team should be able to identify the reason it exists, its owner, its verification method and the releases in which it changed.
Software provenance and signed build evidence
SLSA defines provenance as verifiable information describing where, when and how a software artifact was produced. In practical CI/CD systems, this can be implemented through signed artifact attestations, immutable build metadata and verifiable links between source commit, workflow and binary or container image. GitHub's artifact attestation model, for example, can bind a build to its repository, commit SHA, workflow and triggering event.
For enterprise SaaS, build provenance is not just a security feature. It is a governance primitive. It supports incident scoping, customer assurance, forensic analysis, controlled rollback, supplier due diligence and proof that a reviewed code state corresponds to the deployed artifact.
SBOM and dependency governance
A Software Bill of Materials should be generated as part of the build pipeline where proportionate to the product risk. The SBOM is most valuable when linked to dependency lockfiles, vulnerability scanning, licence review, provenance and release metadata. A static spreadsheet of libraries quickly becomes stale; a release-bound SBOM is operational evidence.
4. Legal gates should be placed at the same points as engineering gates
Legal review becomes scalable when it is attached to lifecycle events rather than calendar events. The following model is deliberately operational: each stage produces technical artifacts and legal evidence that can be reviewed, versioned and reused.
| Lifecycle stage | Engineering outputs | Legal / regulatory gate | Evidence to retain |
|---|---|---|---|
| 1. Product framing | Product scope, users, deployment model, jurisdictions, critical user journeys | Regulatory perimeter, B2B/B2C qualification, data roles, sector classification, AI role mapping, consumer and accessibility scope | Legal scope memo, product taxonomy, assumptions register |
| 2. Requirements | Functional and non-functional requirements, SLOs, RTO/RPO, data classification | Translate mandatory rules into system requirements: minimisation, retention, security, logging, portability, human oversight, accessibility | Requirements matrix linking legal sources to acceptance criteria |
| 3. Architecture | System diagrams, DFDs, trust boundaries, ADRs, API contracts, tenancy and identity model | Privacy-by-design review, transfer/residency analysis, supplier allocation, DPIA trigger, sector-specific architecture constraints | Approved ADRs, data-flow map, controller/processor map, risk decisions |
| 4. Build | Code, IaC, schemas, migrations, dependencies, feature flags | Open-source licensing, third-party terms, secure development requirements, restricted-data controls, AI provider terms | Code review, licence/SCA results, supplier approvals, exceptions |
| 5. Verification | Unit/integration/contract tests, ASVS-derived security tests, SAST/DAST/SCA, accessibility tests, resilience tests | Evidence that mandatory controls are actually implemented; unresolved high-risk deviations require explicit approval | Test reports, risk acceptances, DPIA updates, release checklist |
| 6. Release | Signed artifact, SBOM, provenance, deployment manifest, versioned configuration | Terms, privacy notices, DPA/SCC package, consumer disclosures, conformity or sector documentation where applicable | Release dossier linking code, artefact, legal documents and approvals |
| 7. Operations | Observability, audit logs, vulnerability management, backups, incident response, deletion and export jobs | Breach/incident workflows, data-subject rights, AI monitoring, CRA/NIS2/DORA reporting where applicable, retention enforcement | Operational logs, incident records, vulnerability records, monitoring evidence |
| 8. Change | New ADR, migration plan, regression testing, controlled rollout | Change impact on DPIA, legal basis, AI classification, contracts, security posture, regulatory status | Superseding ADR, change approval, updated compliance matrix |
A legal gate should be testable whenever the obligation is testable
Some obligations can be translated directly into automated controls: encryption policy, TLS configuration, MFA, default retention values, regional deployment, log immutability, dependency thresholds, accessibility checks, API authentication, deletion workflows and export availability. Those controls should be evaluated in CI/CD or continuous monitoring whenever technically feasible.
Other questions remain judgment-heavy: whether a processing purpose is compatible, whether legitimate interests prevail, whether an AI use is high-risk, whether a security measure is proportionate, or whether a customer commitment creates unacceptable liability. Those should not be forced into fake automation. The correct architecture distinguishes deterministic compliance checks from professional legal judgment.
5. Secure software development is now both an engineering baseline and a regulatory expectation
NIST SSDF provides a useful lifecycle structure for secure development. OWASP ASVS 5.0.0, released in 2025, provides a detailed basis for verifying web-application security controls and can be converted into product-specific security requirements and test cases. SLSA adds supply-chain provenance and integrity concepts. Together, these frameworks support a practical DevSecOps model in which security requirements are not merely policy statements but release conditions.
A serious CI/CD security baseline
- Source control: protected branches, mandatory peer review, signed or otherwise attributable changes, least-privilege repository access.
- Secrets: no production secrets in source; central secret management; rotation and scoped service identities.
- SAST and secret scanning: automated checks on each material change, with severity thresholds and managed exceptions.
- Software composition analysis: dependency inventory, vulnerability scanning, licence classification and controlled update policy.
- Infrastructure scanning: policy checks on cloud permissions, network exposure, storage encryption, logging and insecure defaults.
- Container and artifact scanning: known-vulnerability and policy checks before promotion.
- Build provenance: reproducible or at least attributable builds, immutable version identifiers, signed attestations where appropriate.
- Environment separation: development, test and production separated by identity, data and deployment controls.
- Controlled migrations: database and schema changes versioned, reviewed, tested and reversible where feasible.
- Release promotion: production deployment from an approved build, not from an engineer's workstation.
NIS2 and the software supply chain
NIS2 Article 21 requires covered entities to address supply-chain security and security in the acquisition, development and maintenance of network and information systems, including vulnerability handling and disclosure. It also requires assessment of the cybersecurity practices and secure-development procedures of direct suppliers. Italy transposed NIS2 through Legislative Decree No. 138 of 4 September 2024.
This matters even for a SaaS vendor that is not itself directly within NIS2 scope. Enterprise customers that are essential or important entities will increasingly push NIS2-derived security requirements into procurement, contracts, questionnaires and audit rights. A vendor that can produce traceable development evidence answers those requests faster.
Cyber Resilience Act: scope must be analysed, not assumed
The Cyber Resilience Act applies to products with digital elements and certain integrated remote data processing solutions. Pure standalone SaaS is not automatically a CRA product. The Regulation itself distinguishes cloud services that are integral remote data processing for a product with digital elements from cloud services developed outside the manufacturer's responsibility for such a product. Scope therefore depends on the product architecture and market model.
The CRA's main substantive application starts on 11 December 2027, while Chapter IV has applied since 11 June 2026 and Article 14 reporting obligations apply from 11 September 2026. For products that will be in scope, waiting until 2027 to create vulnerability handling, secure-by-default architecture and technical evidence would be poor engineering economics.
6. Data architecture and AI architecture are legal architecture
GDPR: design choices must embody the principles
GDPR Article 25 requires appropriate technical and organisational measures both when the means of processing are determined and during processing. For engineers, this should be translated into concrete architecture decisions: what data is collected, which service can access it, what identifier is necessary, how long it is retained, which telemetry is optional, where encryption applies, how deletion propagates, and how access is audited.
A Data Protection Impact Assessment under Article 35 is not an after-the-fact legal document. For high-risk processing it should be treated as a design-control process. Its risk assumptions should be linked to system diagrams, threat models, data-flow records and mitigation tasks. If the architecture materially changes, the DPIA may need to change with it.
Data residency and international transfers
Region selection should be an ADR, not a hidden cloud setting. The decision should record where primary data, backups, logs, support access and subprocessors are located; which transfer mechanism is relied upon when Chapter V GDPR is engaged; and what technical controls reduce exposure. Multi-region resilience, legal localisation and customer residency commitments need one coordinated architecture rather than three separate conversations.
AI Act: lifecycle evidence, not a model disclaimer
The consolidated AI Act now applies on a staged basis. Its architecture-relevant concepts include risk management, data governance, technical documentation, logging, human oversight, accuracy, robustness, cybersecurity and post-market monitoring. Following the 2026 amendments, the application dates for major high-risk-system obligations differ depending on the classification route, so product teams must work from the current consolidated text rather than from older implementation calendars.
For AI-enabled SaaS, an engineering/legal design review should at least record: the system's role and intended purpose; provider/deployer allocation; model and data lineage; evaluation metrics; prompt and output logging policy; user transparency; human review points; failure modes; security against prompt injection or tool abuse; third-party model terms; and mechanisms for model/version change control.
Where generative AI is integrated into an application, the software team should also distinguish the model layer from the application layer. Model safety does not replace application security. Authentication, authorisation, data isolation, tool permissions, retrieval boundaries, secrets, logging and downstream validation remain application responsibilities.
Data Act: portability must influence SaaS architecture
The Data Act has applied since 12 September 2025 and includes a dedicated switching regime for data processing services. For SaaS providers, Articles 23 to 30 are particularly relevant to termination, exportable data, switching assistance, open interfaces and machine-readable export. The legal obligation and the technical exit architecture should therefore be designed together.
A SaaS platform that stores customer data in proprietary structures with undocumented dependencies may face a much more expensive compliance problem than a platform that, from the outset, separates customer-owned exportable data, provider-internal metadata and protected intellectual property. Exit design is an architectural decision.
7. Specialist regulations should be treated as architecture overlays
There is no single “SaaS regulation”. The applicable stack depends on the service, users, sector, data and business model. The base software-assurance pipeline should therefore support overlays that add requirements without replacing the core engineering process.
| Product / sector | Typical legal overlay | Architecture consequences |
|---|---|---|
| Financial services and regulated ICT | DORA and its technical standards; potentially PSD2/other sector rules depending on activity | ICT asset classification, resilience, change management, environment controls, testing, third-party risk, incident evidence |
| AI-enabled systems | AI Act, GDPR, sector law | Risk classification, model/data lineage, logs, evaluation, human oversight, change control, monitoring |
| Cloud / SaaS data processing services | Data Act, GDPR, NIS2 where in scope or contractually flowed down | Open interfaces, exportability, switching, portability, supplier controls, security evidence |
| Connected products | Cyber Resilience Act where scope is met; NIS2 supply-chain expectations | Secure-by-default product design, vulnerability handling, support periods, technical documentation, reporting readiness |
| B2C e-commerce and covered digital services | European Accessibility Act / Italian Legislative Decree No. 82/2022, consumer law; DSA where intermediary-service functions are present | Accessible design system, keyboard/screen-reader flows, accessible identification/payment, transparent user journeys, complaint and content workflows |
| Health / medical software | GDPR special-category data plus medical-device rules where software qualifies as a medical device | Stricter risk management, validation, traceability, change control and clinical/regulatory evidence depending on classification |
DORA is a useful example of legal rules that look like engineering governance
DORA requires financial entities to identify and document ICT-supported functions, assets and dependencies, assess ICT risk on major changes, and maintain high standards of availability, authenticity, integrity and confidentiality. The delegated technical standards also require clear functional and non-functional requirements before acquisition or development, testing before first use and before production changes, and controlled change management.
Those are recognisable senior-engineering practices. The legal contribution is to determine when they are mandatory, what evidence must exist, how governance responsibilities are allocated and how vendor contracts must support the operating model.
Accessibility is also a release-quality attribute
The European Accessibility Act applies to specified products and services, including e-commerce services, with accessibility obligations applicable to covered offerings from 28 June 2025. Italy implemented the Directive through Legislative Decree No. 82/2022. Accessibility should therefore be represented as requirements and automated/manual test cases in the design system and release pipeline, not as a cosmetic remediation project after launch.
8. The operating model: senior engineers and senior legal counsel working on the same artifacts
Embedding legal expertise does not mean that every pull request needs a lawyer. That would be inefficient. The scalable model is to define trigger-based collaboration.
Engineering owns the architecture
Senior engineers own system design, reliability, security implementation, delivery automation and technical trade-offs. They document decisions in forms that can be reviewed and tested.
Legal owns legal qualification
Senior counsel identifies applicable rules, interprets risk-based standards, maps roles and responsibilities, reviews regulatory assumptions and determines where human legal judgment is required.
Shared ownership of controls
When an obligation becomes a technical control, both disciplines agree on the requirement, implementation intent, evidence and change trigger. Neither side should rely on ambiguous hand-offs.
Escalation by architectural event
Legal review is triggered by events such as a new data category, new region, new AI model, new subprocessors, new high-risk feature, change in retention, new marketplace function or material authentication redesign.
The compliance matrix should be executable where possible
A mature product team can maintain a machine-readable or structured control catalogue that links each requirement to owners, services, tests and evidence. Some gates can then be enforced automatically through CI policy: no release with critical vulnerabilities, no public storage bucket, no unsigned production artifact, no schema change without migration tests, no unsupported dependency, no missing accessibility test for a critical journey.
Legal rules should not be reduced to code where they require interpretation, but the implementation consequences of a legal decision often can and should be encoded.
What this changes commercially
The strongest reason to adopt this approach is not fear of sanctions. It is product velocity. A traceable compliance architecture makes due diligence, enterprise procurement, security questionnaires, data-protection reviews, customer audits, incident response and future certification materially easier because the evidence already exists.
It also improves maintainability. When a new regulation, customer requirement or architectural constraint appears, the team can perform impact analysis against a known graph of services, data flows, ADRs, controls and dependencies instead of reopening the entire product.
The objective is a repeatable release dossier. For every production version, the organisation should be able to reconstruct: what changed, who approved it, which requirements applied, which tests passed, which dependencies shipped, how the artifact was built, which legal documents corresponded to the release, and what residual risks were consciously accepted.
9. Conclusion: legal compliance can be an accelerator only when it becomes engineering information
A SaaS platform or app reaches the market faster when its architecture is designed to absorb legal constraints early, not when legal review is skipped. The difference is timing and structure.
When legal counsel enters at the end, compliance creates rework. When legal analysis is translated into requirements, ADRs, control objectives, tests and evidence at the beginning, it becomes part of the product's engineering system. The architecture becomes traceable. The release process becomes repeatable. The compliance position becomes verifiable. Change becomes easier to assess. Enterprise customers receive better evidence. Incidents can be scoped faster.
The competitive advantage is therefore not “being compliant” as a static state. It is having a compliance-capable software architecture: a delivery system engineered to show, release after release, why the product is built the way it is and which evidence supports that decision.
For technology companies operating in Italy and the European Union, that capability increasingly sits at the intersection of senior software engineering, cybersecurity, data governance and qualified legal counsel. Treating those disciplines as one design conversation is not bureaucracy. It is modern product engineering.
10. Engineering and legal sources
- NIST SP 800-218 — Secure Software Development Framework (SSDF) Version 1.1.
- NIST SP 800-218 Rev. 1 — SSDF Version 1.2, Initial Public Draft (December 2025).
- OWASP Application Security Verification Standard (ASVS) 5.0.0.
- SLSA v1.2 — Provenance.
- AWS Prescriptive Guidance — Architectural Decision Record process.
- Regulation (EU) 2016/679 — GDPR.
- Directive (EU) 2022/2555 — NIS2 and Italian Legislative Decree No. 138/2024.
- Regulation (EU) 2024/2847 — Cyber Resilience Act.
- Regulation (EU) 2024/1689 — AI Act, consolidated version of 27 July 2026.
- Regulation (EU) 2023/2854 — Data Act.
- Regulation (EU) 2022/2554 — DORA and Delegated Regulation (EU) 2024/1774.
- Directive (EU) 2019/882 — European Accessibility Act and Italian Legislative Decree No. 82/2022.
- Regulation (EU) 2022/2065 — Digital Services Act.
This article provides a general engineering and legal framework as of 7 September 2026. Regulatory scope depends on the specific product, provider role, sector, users, data, deployment model and jurisdictions. It is not a substitute for a product-specific legal or security assessment.