November 14, 2025
6 mins read
In many boardrooms, conversations about regulatory compliance and software sound deceptively simple: “We need to comply with GDPR.”, “Our system must support ISO 27001.”, “We have to meet FCA reporting requirements.”.
It’s easy to assume that compliance is a technical problem that the engineering team will solve as they build out systems and capabilities. But the reality is that building software to meet regulatory obligations is rarely a purely technical exercise. It’s a joint challenge, one that requires careful orchestration of business processes, customer interactions, data governance, and technology.
Understanding that compliance is multifaceted is critical. Companies that treat compliance as a software feature risk building systems that technically satisfy the law but fail in practice, either by exposing the business to legal risk, creating poor customer experiences, or generating costly operational overhead.
Let’s explore why.
Take one of the most well-known privacy laws: the GDPR “Right to Be Forgotten.” On paper, the requirement is straightforward: an individual has the right to request the deletion of their personal data. But implementing this in a compliant way isn’t as simple as building a delete capability into the software's business logic.
There are two sides to the requirement:
Technical: Your system needs the capability to locate and securely erase all traces of a user’s data, including in backups, logs, third-party systems, data lakes and analytics pipelines. This often requires designing your architecture from the ground up with data deletion in mind.
Business Process: Users must have a way to invoke that right, usually by submitting a request through a web portal, emailing support, or contacting a Data Protection Officer. There must be a process for verifying their identity, assessing exceptions (e.g. legal retention requirements), and confirming completion. Someone needs to own that process.
Without the business mechanism, the technical feature sits unused. Without the technical capability, the business process fails at execution. True compliance requires both.
Modern businesses run on a constellation of tools: CRMs, marketing platforms, billing systems, internal databases, analytics services, and third-party APIs.
Regulation rarely cares about the boundaries between them. If a law states that you must provide a customer with a complete record of their data upon request (as under GDPR or CCPA), then all those systems are in scope.
This creates two challenges:
TechnicalYou need visibility into where data lives, APIs or pipelines to retrieve it, and mechanisms to keep it consistent across environments. This may involve significant architectural investment.
OperationalSomeone needs to coordinate those requests. Who checks that the data package is complete before it’s sent to the customer? How do you ensure a marketing vendor also deletes data when a user requests erasure? These aren’t coding tasks, they’re business ones.
Failing to design the organisational process around these obligations often leads to technical solutions that are brittle, manual, or incomplete.
Many regulatory requirements involve conditional decisions and those decisions often sit firmly in the realm of business policy, not engineering.
For example:
Financial services (FCA, SEC)Certain trades or communications must be retained for a minimum period, while others must be deleted after a maximum period. Determining which is which often depends on the type of customer, the product involved, or the jurisdiction, all of which are business rules before they are code.
Healthcare (HIPAA)Data access logs must be maintained and auditable. But who can see what data, under what circumstances, depends on clinical workflows and consent policies.
Payments (PSD2)Strong Customer Authentication (SCA) requirements apply to certain transactions but not others. Whether an exemption applies is often a commercial or legal decision which then needs to be expressed as code.
In all of these cases, engineers can build robust systems but only if the business has clearly defined the underlying decision-making framework.
Another common mistake is treating compliance as a project with a start and end date. You “build the feature,” tick the box, and move on.
But most regulations, from data privacy to financial reporting, have ongoing obligations. Customers can make new requests, laws evolve, your business model changes, new integrations are added, etc.
That means compliance isn’t just about the initial build, it’s about:
MonitoringAre requests being handled within legal timeframes?
AuditingCan you demonstrate compliance when challenged?
TrainingDo staff know how to escalate unusual requests?
GovernanceAre new systems or vendors onboarded in a compliant way?
All of these elements are fundamentally organisational in nature — they rely on well-defined responsibilities, clear policies, and consistent execution. Technology can enable and streamline them, but it cannot replace the human judgement, governance, and accountability that make compliance sustainable.
The most successful companies treat regulatory requirements not as a burden but as a catalyst for building better systems and stronger trust with customers.
For example:
Apple’s privacy controls don’t just meet GDPR requirements – they form a key part of the company’s brand promise.
Fintech startups that build regulatory reporting capabilities directly into their data platforms gain an advantage when scaling into new markets.
Healthcare providers that integrate consent management workflows into patient portals create smoother patient experiences while reducing legal risk.
In each case, compliance isn’t just a line item in the engineering backlog, it’s part of the product and business strategy.
Delivering the technical mechanics of compliance is only part of the picture. These capabilities are essential, but on their own they rarely satisfy the full intent of a regulatory requirement.
Real compliance depends on the framework that surrounds those capabilities: clear policies that define how obligations are met, processes that guide how requests are handled, and procedures that ensure decisions are recorded, reviewed, and auditable. Technology enables these things, but it cannot replace them.
The organisations that approach compliance most effectively treat it as a cross-functional discipline. Engineering, legal, operations, product, and leadership work together from the outset to design systems and workflows that are both technically robust and operationally sound.
In a regulatory environment that is only growing more complex, that holistic approach is more than just a defence against fines or investigations. It’s a foundation for trust, resilience, and the ability to adapt as both the business and the rules evolve.
At The Curve, we work with organisations that are modernising their systems and processes, whether that’s to meet new regulatory requirements, to embed compliance more effectively into how they operate, or simply to ensure that future digital platforms are designed with these obligations in mind from the outset.
Our Digital Transformation Discovery is a structured engagement that brings business and technical stakeholders together to map current processes, identify gaps, and shape a clear roadmap for change. That might mean designing new platforms that inherently support compliance, streamlining the way requests and approvals flow through the organisation, or reimagining legacy workflows so they’re fit for the next decade.
By aligning technology, policy, and process from the very start, we help organisations not only meet their obligations today, but build the capability to adapt confidently as the regulatory and business landscape evolves.