IT Business 6 min read

Architectural readiness for EU requirements: implementing core compliance

A shift from legal patches to Compliance-by-Design: how to integrate GDPR and CRA requirements into your architecture to avoid critical technical debt.

The approaching 2026 deadline for EU market expansion requires Ukrainian product companies to fundamentally change their approach. The European market is no longer just a promising direction; it is now a space governed by strict regulatory rules, ranging from classic GDPR to the new requirements of the Cyber Resilience Act (CRA). Attempting to solve compliance issues solely through a legal department or via superficial code patches creates a critical compliance debt. For CEOs and CFOs, this risks resulting in a product that is technically impossible to scale without a complete overhaul of the core.

Transitioning to a Compliance-by-Design concept is a strategic financial decision, not merely a legal recommendation. Integrating regulatory requirements directly into the architectural foundation of a product during the release planning stage helps avoid massive re-engineering costs and ensures a stable entry into EU markets.

The cost of compliance debt: why cosmetic changes are more expensive

Many IT product owners still perceive security and privacy requirements as an external add-on. There is a common misconception that updating a Privacy Policy, adding a cookie consent banner, and implementing basic encryption is sufficient for the European market. However, when a system faces real cross-border audit requirements, it often becomes clear that the architecture cannot ensure physical data isolation or provide an immutable user activity history.

Attempting to layer compliance over a finished, unadapted architecture leads to a sharp increase in development costs. According to analytical estimates, retrofitting security and privacy into an existing legacy system can cost significantly more than building the system with these requirements in mind from the start. Beyond direct financial losses, the company faces a critical deficit in time-to-market: while competitors are selling, your engineers spend months rewriting database logic.

Compliance-by-Design: regulatory readiness starts at the core

True architectural resilience requires moving away from a reactive approach (compliance-as-a-patch) in favor of proactive design. According to resources like GeeksforGeeks, the best way to ensure GDPR compliance is to integrate privacy controls directly into the system design rather than treating them as an additional task after development is complete. Architectural researchers, including those published on the PMC platform, emphasize the importance of binding privacy policies directly to data (sticky policies) in cloud architectures, which guarantees control regardless of how that data is moved.

Three pillars of technical compliance: RBAC, Row-Level Security, and immutable audit

To ensure a product passes the scrutiny of European B2B clients and regulators, its core must rely on three fundamental technological mechanisms:

  • Role-Based Access Control (RBAC): Authorization must function not only at the user interface level but also deep within the API and database schema levels. Every entity must be strictly regulated.
  • Row-Level Security (RLS): This is a critical element for multi-tenant SaaS platforms. RLS ensures that a client from one EU country cannot physically access data from another jurisdiction, as the isolation policy is applied automatically without complicating application code.
  • Immutable Audit Trail / Data History: Any interaction with data must be recorded in a centralized, tamper-proof log. This creates an immutable history, which is a basic requirement for regulatory reporting in the EU.

Automation versus manual control: challenges of the Cyber Resilience Act (CRA)

The EU Cyber Resilience Act (CRA) changes the rules of the game: security must be proven at all stages of the product lifecycle. As analysts at EE Times note, achieving compliance with EU CRA requirements necessitates automation, as manual processes are no longer effective. Automated compliance checks and deep architectural integration allow for a dramatic reduction in manual audit costs compared to traditional methods that relied on paper documentation.

Platform approach: minimizing costs with ready-made frameworks

Implementing RLS, RBAC, and immutable auditing from scratch requires thousands of hours of work. To optimize costs, product companies should consider using platform foundations that already include these mechanisms at the core level.

An example of such a technological foundation is UnityBase, a full-stack JavaScript low-code platform for rapid enterprise application development. UnityBase is a joint development of the Intecracy Group, which is an alliance of independent companies linked by partner agreements and share exchanges (where InBase acts as a key, but not the only, developer). The platform provides domain metadata management at the core level and includes built-in access control mechanisms (RBAC and RLS), REST API generation tools, and immutable user activity logs (Audit Trail). Using such certified mechanisms within the UnityBase platform allows developers to focus on business logic while leaving basic compliance to the architectural foundation.

Position of the Software Ukraine Legal Committee: protecting the IT business

Technical readiness must be accompanied by an adequate regulatory policy. The Legal Committee of the Software Ukraine Association actively forms positions regarding Ukrainian and European product IT regulations. The main goal is to oppose requirements that are disproportionate for small and medium-sized enterprises.

However, it is important to understand that using any technology platform, even the most secure one, does not guarantee full legal compliance without a professional legal audit. Compliance is not a one-time project, but a continuous process of architectural evolution.

Architectural readiness scale for EU requirements (Compliance Maturity)

Readiness LevelTechnical ImplementationFinancial and Regulatory Risks
Level 0 (Reactive)Compliance is handled via legal disclaimers and manual data exports upon request.High risk of critical fines from EU regulators and audit failure.
Level 1 (Applicative)Security logic and GDPR requirements are manually written at the business application code level.High risk of errors during system updates. Rapid accumulation of technical debt.
Level 2 (Architectural)Access control (RBAC) and data isolation (RLS) are integrated directly into the database schema. Audit logs are immutable.Minimal risk of data leakage, but requires significant initial investment in design.
Level 3 (Platform/Automated)Uses a ready-made framework (e.g., UnityBase mechanisms) where security and automated requirements are embedded in the core.Lowest time-to-market. Automation reduces manual audit costs.

FAQ

How do you design a system architecture in accordance with GDPR requirements?

Design should be based on Privacy-by-Design principles from the very beginning of development, rather than as an add-on. This includes integrating privacy controls, ensuring data isolation (RLS), and binding privacy policies directly to the data storage architecture.

What technical requirements does the EU Cyber Resilience Act (CRA) impose on software products?

The CRA requires a shift from manual checks to full automation of security controls at all stages of the product lifecycle. This allows for effective risk management and compliance with resilience standards without placing a disproportionate burden on company resources.

How do you implement Row-Level Security (RLS) to isolate European user data?

RLS is implemented at the database core level or through a platform metadata model. This allows security policies to be automatically applied to every query, ensuring that users only access permitted data, regardless of the application logic.

Data sources