COMPLIANCE IN EUROPEAN SOFTWARE DEVELOPMENT
Does the software meet the requirements that apply in each European market, and is the supplier itself safe to place inside a regulated supply chain? Modsen answers both – requirements translated into architecture, and a delivery setup prepared for a vendor audit.
Two layers of compliance
Regulation reaches a software project from two directions at once, and they are handled differently. We account for both product‑level requirements and supplier‑side compliance when setting up the engineering process.
Inside your product
Requirements become data fields, workflows, permissions, logs and reports. The evidence a supervisor or auditor may ask for can be generated by the system rather than assembled manually after the fact.
Modsen Modsen translates applicable regulatory requirements into technical requirements and builds them into the product architecture and workflows.
Inside Modsen delivery
A data processing agreement, sub‑processor list, access model and security documentation are prepared as part of onboarding. Under NIS2 and DORA, supply‑chain and ICT third‑party risks can become part of your compliance obligations.
Modsen Modsen accounts for these requirements in the delivery setup and prepares the documentation needed for relevant supplier assessments.
Rules that affect European projects
Industry regulation sits on top of a horizontal layer that may apply depending on the product, data and markets involved.
GDPR (and UK GDPR)
What we build or account for in the software
Lawful basis for each processing activity, retention and deletion rules, subject‑rights requests built as product functions, transfer documentation
Applies
Since May 25, 2018
NIS2
What we build or account for in the software
Logging, incident handling inside national deadlines, access control, security requirements passed down to your own suppliers
Applies
National laws following the Oct 17, 2024 transposition deadline; scope and dates differ per country
European Accessibility Act
What we build or account for in the software
Keyboard navigation, screen‑reader support, accessible form errors and authentication, aligned with EN 301 549
Applies
Since Jun 28, 2025
EU Data Act
What we build or account for in the software
Access to data generated by connected products, switching and exit provisions in cloud arrangements
Applies
Since Sep 12, 2025
EU AI Act
What we build or account for in the software
Risk classification, applicable transparency and disclosure requirements, human oversight, documentation and logging controls depending on the AI system and its risk category
Applies
General rules from Aug 2, 2026; Annex III from Dec 2, 2027; Annex I from Aug 2, 2028
Cyber Resilience Act
What we build or account for in the software
Secure‑by‑design requirements, vulnerability handling process, software bill of materials for products with digital elements
Applies
Reporting duties from 11 Sep 2026; full application from 11 Dec 2027
Europe is not one jurisdiction
A product sold in four European countries can sit under different supervisors, and the architecture has to allow for that. Modsen designs shared cores with jurisdiction‑specific rules isolated in configuration, workflows and integrations, so country‑specific requirements can be handled without rebuilding the whole platform.
EU and EEA
EU regulations such as the GDPR apply directly across EU Member States, while directives such as NIS2 are implemented through national law.
EEA countries apply relevant EU legislation after its incorporation into the EEA Agreement
EU hosting and data residency can be handled through configuration
United Kingdom
The UK runs its own rulebook alongside the EU one, with its own regulators and reporting routes.
UK GDPR and UK regulatory requirements, overseen by regulators such as the ICO, FCA and PRA
UK‑specific customs, VAT and import/export requirements for cross‑border transactions
Trusted expertise across different European regions
Compliance by industry
Each domain adds its own rulebook on top of the horizontal layer. We account for these industry‑specific requirements when designing and engineering the relevant software. What that means in practice is set out on the domain pages.
Fintech
PSD2 strong customer authentication and TPP access
DORA ICT risk management and third‑party arrangements
AMLR‑ready KYC and monitoring MiCA disclosures
MiCA disclosures
FCA requirements for the UK market
E-commerce
Destination VAT, OSS and IOSS
Country e‑invoicing formats
Omnibus price history
GPSR product data
Accessibility under the EAA
DSA duties for marketplace models
Logistics
eFTI and e‑CMR datasets
Smart Tachograph 2 data and cabotage counting
ICS2, NCTS and AES customs integrations
CO2 figures per shipment under ISO 14083
Fintech
PSD2 strong customer authentication and TPP access
DORA ICT risk management and third‑party arrangements
AMLR‑ready KYC and monitoring MiCA disclosures
MiCA disclosures
FCA requirements for the UK market
E-commerce
Destination VAT, OSS and IOSS
Country e‑invoicing formats
Omnibus price history
GPSR product data
Accessibility under the EAA
DSA duties for marketplace models
Fintech
PSD2 strong customer authentication and TPP access
DORA ICT risk management and third‑party arrangements
AMLR‑ready KYC and monitoring MiCA disclosures
MiCA disclosures
FCA requirements for the UK market
E-commerce
Destination VAT, OSS and IOSS
Country e‑invoicing formats
Omnibus price history
GPSR product data
Accessibility under the EAA
DSA duties for marketplace models
Logistics
eFTI and e‑CMR datasets
Smart Tachograph 2 data and cabotage counting
ICS2, NCTS and AES customs integrations
CO2 figures per shipment under ISO 14083
Modsen compliance audit in practice
Value
100% of regulatory compliance gaps eliminated
45% lower security breach risk
9 months to a certificate of compliance
Fintech app audit: product assessment for European certification compliance
IT auditing
Challenge
A north‑eastern European payments and remittance app needed to clear GDPR, KYC, PCI DSS, EFTA, AES and ISO 27001 requirements.
Solution
Four Modsen consultants audited data protection, money‑transfer and user‑security compliance in 3.5 weeks, then delivered a 15+ page remediation plan covering MFA, tokenisation, penetration testing and disaster recovery.
Value
100% of regulatory compliance gaps eliminated
45% lower security breach risk
9 months to a certificate of compliance
Value
100% of security compliance gaps eliminated
€0 in regulatory fines
Certificate of compliance obtained
Fintech company audit: security standards compliance
IT auditing
Challenge
An Eastern European crypto trading platform needed its web and mobile apps assessed against ISO/IEC 27001 and 27002, OWASP ASVS, BSS, CCSS, PCI DSS and BSA before certification.
Solution
Five Modsen consultants ran penetration testing ahead of the audit, documented gaps in encryption, access control and account creation over 2.5 weeks, and handed over a prioritised remediation plan.
Value
100% of security compliance gaps eliminated
€0 in regulatory fines
Certificate of compliance obtained
Discuss compliance for your product
Tell us which markets you operate in and what you are building. You will get a view of which requirements land in the software and which stay outside it.
AI use that follows your security policies
AI doesn't have to be used the same way on every project. We adapt its role in the engineering workflow to your European regulatory environment, security policies, data restrictions, and internal AI governance.
No‑AI delivery
For projects where client policies, sensitive data, or security requirements restrict the use of LLM tools, development can run without AI in the engineering workflow.
Restricted environments
Sensitive IP
Client‑mandated AI restrictions
Controlled AI use
AI supports selected engineering tasks within agreed boundaries, while code, architecture, security decisions, and production changes remain under senior engineer review.
Enterprise software
Regulated products
Established security policies
AI‑augmented delivery
AI is used more broadly across approved development and QA workflows to accelerate routine work, with human review and the same security and quality gates applied before release.
Faster release cycles
Routine development at scale
Expanded QA coverage
How Modsen works as your supplier
A vendor questionnaire is faster to answer when the answers already exist.
Contractual documents prepared
We prepare the documentation required for an engagement, including DPAs, Technical and Organisational Measures (TOMs), NDAs, and a disclosed sub‑processor list covering cloud providers and tooling.
Least‑privilege access
Modsen assigns named engineers, provides logged access to client systems, and follows a defined procedure for returning or deleting data at the end of an engagement.
Security policies and reviews
Modsen applies internal security policies informed by ISO/IEC 27001 and OWASP guidance. Project‑specific security reviews and penetration testing are performed where required.
EU‑hosted environments
Our company can place hosting, development, and test environments inside the EU when data residency forms part of the client's obligations.
Ready for your supplier assessments
We supply the documentation needed for DORA ICT third‑party assessments and NIS2 supplier reviews.
Defined AI boundaries
Our AI‑augmented delivery model keeps your source code, personal data and payment data outside external LLM workflows.
What Modsen does, and what stays with you
Modsen delivers
Architecture and code that carry the requirements Integrations with supervisory and customs systems Registers and logs Reporting exports Technical evidence behind them
You and your advisers keep
Licences (PI, EMI, CASP and equivalents) Legal and regulatory classification of your AI use cases DPO decisions Customs brokerage Everything actually filed with a supervisor
How compliance enters the work
Rules discovered after launch are expensive because fixing them means touching the core. Modsen front‑loads that discovery.
Applicability map
We map the requirements that apply to the specific product and target countries: which acts apply, where they apply, and which requirements need to be reflected in the software. The resulting document gives your legal advisers a concrete basis for review.
Architecture
A shared core is designed with country‑specific rules isolated in configuration, workflows, and integrations. Entering another market then means adding the relevant rule set and adapters rather than rebuilding the core.
Evidence collected as we build
Logs, registers, test results and technical documentation accumulate during development, so an audit or certification review runs on prepared artefacts.
Change tracked against dates
Relevant regulatory deadlines are added to the delivery backlog with implementation tasks and owners. This puts required changes into the same planning process as other engineering work.
Compliance in European software development: FAQ
Is Modsen a compliance consultancy?
Does one platform work across the EU and the UK?
Will you sign a DPA and appear in our supplier register?
Can compliance be added to an existing product?
