A Guide to Compliance by Design

The phrase “compliant by design” grew out of earlier related terms, “private by design” and “secure by design.” Ann Cavoukian, then Ontario's information and privacy commissioner, published seven principles of “privacy by design” in 2009, the first of which insists that "privacy by design comes before-the-fact, not after.” The US Cybersecurity and Infrastructure Security Agency later made a similar argument for security, contending that "out-of-the-box, products should be secure"—for example, with features such as multifactor authentication available at no extra cost.

Compliance by design extends this approach to any regulatory obligation: the consultancy Projective Group describes it as "applying a systematic approach to integrating regulatory requirements into manual and automated tasks and processes."

The alternative, of course, would be designing without an eye towards compliance, then retrofitting compliance features to the already-designed product. But this forces controls into legacy systems and manual processes that were never built to hold them. In practice, it often leads to an unwelcome choice: ship something non-compliant, or delay a launch to deal with retrofitted compliance. A risk assessment run at the end of a process can catalog compliance risks after the fact—but a smartly designed process can effectively build that risk assessment into the very process of building.

One major risk, of course, is fines. In November 2022, for instance, Ireland's Data Protection Commission fined Meta Platforms Ireland EUR 265 million for, effectively, a design failure. Contact-import and search tools on Facebook and Instagram had been abused to scrape data on roughly 533 million users, Infosecurity Magazine reported. The commission found breaches of Article 25(1) and 25(2), data protection by design and by default.

But fines don’t represent the entire possible bill. IBM's Cost of a Data Breach Report 2026, produced with the Ponemon Institute, puts the global average cost of a breach at $4.99 million, a record high and a 12% rise on the year. Ponemon's earlier study with the security vendor Globalscape put annual non-compliance costs at 2.71 times compliance costs in 2017: $14.82 million against $5.47 million. This is to say nothing of reputational risk, a difficult-to-quantify cost that often is not listed in a compliance management budget—even if perhaps it should.

Regulators increasingly write rules about what a system must do to assure compliance, even before it goes live. MiFID II, the EU markets rule applicable since January 2018, was just one early example.

Four current regimes are worth unpacking in some detail, many of them extending beyond financial institutions. The first three are European; the last is in the U.S.

• GDPR Article 25
• CSRD and sustainability reporting
• The EU AI Act
• HIPAA

Article 25 obliges controllers (that is, the organizations that decide why and how personal data gets processed) to build in safeguards such as pseudonymization, which swaps identifying details for stand-in values. Another provision requires that "by default, only personal data which are necessary for each specific purpose of the processing are processed."

The EU's Corporate Sustainability Reporting Directive (CSRD) obliges large firms to report standardized sustainability data. In December 2025, the European Parliament narrowed scope to companies with more than 1,000 employees and net turnover above EUR 450 million; the Council approved it on 24 February 2026. White & Case reads the new thresholds as applying from financial years starting on or after 1 January 2027. In terms of compliance-by-design, CSRD still pushes firms to capture sustainability and supply chain due-diligence data inside their systems, rather than assembling disclosures by hand.

The EU AI Act's obligations for high-risk systems, such as hiring and credit-scoring tools, apply from 2 December 2027 (pushed back from the original August 2026 date). The evidence they require can only be generated while a system is being built. Before reaching the market, such a system's provider has to operate a risk-management system (Article 9), govern its training data, produce technical documentation, keep logs, design for transparency and human oversight (Articles 13 and 14) and pass a conformity assessment (Article 43). The latter is defined in Article 3 as "the process of demonstrating whether the requirements ... have been fulfilled.”

On 6 January 2025 the US Department of Health and Human Services' Office for Civil Rights (OCR) proposed the first overhaul of the HIPAA Security Rule since 2013. It remains a proposal: HIPAA Journal reports the final rule is expected in July 2027. As drafted, it would make mandatory many compliance-by-design-related safeguards that some healthcare organizations may currently treat as merely "addressable": these include multifactor authentication and encryption of electronic protected health information.

Compliance by design turns regulations into compliance controls that software can evaluate. Then it runs those evaluations continuously inside the process that builds the product. Three important components of compliance by design include

• Turning the rulebook into machine-readable controls
• Writing the policy “as code”
• Putting compliance in the backlog—rather than in the launch gate

For example: a control such as NIST’s “AC-2: account management” in the US standards agency NIST's security catalog ceases to be a plain paragraph in a PDF—instead becoming structured data tools can read and validate. One format compliance professionals can rely on is Open Security Controls Assessment Language (OSCAL), which NIST describes as open and machine-readable in XML, JSON and YAML, and which it says can cut audit timelines "from months to just minutes." In 2022, Amazon Web Services became the first cloud service provider to submit a FedRAMP System Security Plan—the core document in US government cloud authorization—in OSCAL format.

Frameworks for this abound. Open Policy Agent (OPA) is one widely used engines in this category; it evaluates a requirement written in “rego” (OPA’s policy language) every time an engineer proposes a change. Checkov scans infrastructure-as-code files for misconfigurations against baselines including HIPAA and PCI DSS, the payment-card industry's security standard; HashiCorp's Sentinel and AWS Config do similar work. The cloud security vendor Wiz describes the result as policies that are "versioned in source control, tested in CI/CD pipelines, peer-reviewed in pull requests, and deployed through the same workflows as application code.” In this way, misconfigurations are fixed "before deployment, not after an auditor finds them in production."

Product owners can write compliance requirements into the product development backlog as acceptance criteria. Continuous controls monitoring—that is, automated checking that a control is still working—can then keep evidence up-to-date. Governance, risk and compliance (GRC) teams thus are able to move from inspecting finished work to defining controls proactively, then monitoring their implementation and performance.

At least three benefits can emerge from designing compliance:

• Faster time to market
• Audit readiness (without a scramble)
• Greater transparency with lower risk exposure

A research program from Google reported in 2019 that survey respondents were 2.6 times more likely to be low performers if their organization ran a formal, external change-approval process. It further found no evidence that such reviews actually reduced the amount of changes that fail in production. The suggestion is that lighter weight controls during development can increase speed-to-market without detriment. RegScale, a compliance-as-code vendor, further advertises "60% less audit prep effort.”

Every check that policy-as-code runs can leave a timestamped, machine-readable record. In this way, audit evidence accumulates as a byproduct of running the system—preventing a frantic screenshot hunt conducted just before a deadline. Sometimes, this proactive audit-readiness isn’t really a choice; the AI Act's Article 12 requires high-risk systems to "technically allow for the automatic recording of events (logs) over the lifetime of the system."

IBM counts "reputational damage, erosion of trust among customers and customer churn" among the consequences of a breach. Strategic risk of this sort is a matter for the C-suite: in PwC's 27th Global CEO Survey, 64% of CEOs said the regulatory environment inhibits their company from delivering value; “one significant factor is complexity,” writes PwC, suggesting that anything that can simplify the practice of managing this risk could break the impasse.

PwC's 2025 Global Compliance Survey found that 85% of the executives it surveyed say compliance requirements have grown more complex in recent years. One trend here is the emergence of discourse around so-called “digital sovereignty,” with new regulations—particularly but not exclusively in the EU—increasingly steering firms into ensuring more freedom and control around data, operations, the technology stack and AI.

Fully 63% of executives blamed the complexity and dispersal of data inside their own organizations, suggesting human factors and cultural matters to be as much a cause of the problem as tooling where these programs tend to fail. Indeed, the hope is that new generations of tooling might help steer firms into building seamless cultures of compliance.

Not everyone finds the shift to be solely a burden. The IBM Institute for Business Value, surveying 2,500 technology C-suite leaders across 34 countries in 2024, found that 70% of tech CxOs see regulatory change as an opportunity. And new platforms, like IBM’s Sovereign Core, increasingly exist to help effect compliance by design at scale across organizations.