When compliance is built in, the audit stops being a project

Compliance, compliance-by-architecture, CMMC, ~5 min read

Ask a compliance officer what the worst part of the job is and you will rarely hear “the regulations.” You will hear about the six weeks before an audit. The scramble to find out which control changed, when, and why. The spreadsheet that was accurate in March. The engineer who has left the company and was the only person who knew how the logging worked.

That scramble is a symptom. It happens because compliance was bolted onto a system after the system existed, and the evidence has to be reassembled by hand every time somebody asks for it.

Pierre Ferran made a version of this argument on Finextra on 29 July, in a piece titled Compliance is becoming infrastructure, not overhead. It is written for financial institutions, and the scale he describes is a bank’s scale. The mechanism he identifies is the same one that breaks a 70-person defense supplier trying to hold CMMC.

The seam where compliance actually breaks

Ferran’s diagnosis is precise, and it is worth quoting the shape of it. The bottleneck in a regulated firm is no longer expertise. Financial institutions employ some of the best regulatory specialists in the world, and they are not confused about what any single rule means.

What breaks is everything sitting between the text and the control. Interpreting the rule for this specific business. Mapping it to the products and processes it touches. Finding the gap in the existing policy. Fixing it. Assigning ownership. And being able to prove all of that later, when an auditor asks in 2027 why a control changed in 2025.

He describes the legacy operating model in a way that will be familiar well outside banking. A guideline is published. Someone in legal reads it and writes a summary. A spreadsheet gets updated. A working group is scheduled for three weeks later. Risk, technology, and product each read the same summary and reach slightly different conclusions about what it means for them, and the reconciliation happens in meetings, months before implementation starts. Then the next consultation closes and the cycle restarts.

By his account, a firm operating across a handful of jurisdictions now faces thousands of regulatory developments a day once you count level-one texts, delegated acts, technical standards, and supervisory guidance. Whether or not that number holds for your sector, the direction is not in dispute. Ferran points to DORA, applicable since January 2025, MiCAR, fully applicable at the end of 2024, and the AI Act phasing in through 2026 and 2027, with an AML package and PSD3 behind them. Regulation stopped being an event and became a flow.

Security already made this move

The best part of Ferran’s argument is the analogy he reaches for. There was a time when a security review happened just before a product went live. Today that would be unthinkable. Security is designed in across the whole build, because managing risk after systems exist is slow and expensive.

The closer precedent, he notes, is internal to compliance itself. GDPR already proved the point inside the discipline. Privacy could not be contained in the legal function. Privacy by design had to reach into product decisions, data protection assessments had to involve engineers, and records of processing depended on data teams keeping them current. That was the first obligation that could not be satisfied by a document.

AI is the next one, and it is less forgiving. An obligation about where personal data may be processed is an architectural question before it is a legal one. If your models run in someone else’s cloud, in a jurisdiction you did not choose, on infrastructure whose logging you cannot inspect, you are not going to policy your way out of it. The answer to “where does this data live and who can reach it” is decided by a purchase order, not a paragraph.

What building it in looks like

For a small or mid-sized organization, “compliance as infrastructure” is not an abstraction. It is a short list of decisions made in a particular order.

Residency and jurisdiction come first, because they are the hardest to change later. Which physical facility holds the data, under which country’s law, and who has custody of the keys. Everything downstream inherits from that answer.

Then access, scoped and revocable, with a record. Not a policy that says only authorized personnel may access client data, but a system where unauthorized access is structurally not available and every authorized access leaves a trail nobody can quietly edit.

Then evidence as a byproduct of running, rather than a project that starts eight weeks before the assessor arrives. If your audit trail is generated by the same systems that do the work, the audit stops being an archaeology exercise. You already have the answer to when a control changed, because the change is in the log.

This is what Modular Technology Group means by compliance-by-architecture rather than compliance-by-audit. Private AI infrastructure in a US facility, so residency and jurisdiction are settled facts rather than vendor commitments. Fixed monthly pricing, because a compliance program you cannot budget for is a compliance program that gets deferred. And a program built to satisfy the framework the client is actually held to, whether that is CMMC, NIST 800-171, HIPAA, or FedRAMP alignment, rather than a general posture of being careful.

The economics are the part that usually surprises people. Bolted-on compliance is cheap to start and expensive forever, because every new obligation costs another remediation project. Built-in compliance costs more in month one and then absorbs new requirements as configuration changes. Ferran’s test for a firm is a good one to steal: how long does it take you, from the day a requirement is published, to know which parts of your operation it touches and who owns the response. If the honest answer is months, the problem is architectural.

Your data, your rules, from dirt to desktop

Modular owns the stack from the physical facility through the user interface, which is the only way to answer the residency question without a footnote. One vendor, no handoffs between a cloud provider, a hosting provider, and an AI provider, each of whom can only speak for their own layer.

Compliance has always been the price of operating in a regulated industry. What is changing, and Ferran is right that GDPR started it rather than the AI Act, is that it is turning into the thing that lets you move faster instead of the thing that stops you making mistakes. The firms that get there will not be the ones with the biggest compliance teams. They will be the ones who stopped treating compliance as paperwork and started treating it as plumbing.