From Our CEO: What If Compliance Didn’t Feel Like Compliance?

Anyone who leads a modern organisation has encountered the same moment. A project is ready to move forward  and everything appears on track. Then a familiar late-stage request arrives: “Before we proceed, we need the SBOM.” Or risk management asks for details about a component no one has documented. Or procurement realises the encryption in use might not meet regional requirements.

None of these questions are unreasonable. They simply surface at the wrong time, and while people search for information that should have been captured earlier,  momentum quietly drains away.

This is where the perception must shift. Compliance isn’t the barrier, the timing of compliance is. We’ve allowed it to become episodic, appearing only when someone asks for evidence. But what if that evidence were already available? What if compliance didn’t trigger a pause because it was continuously generated as the work happened? What if we shifted left?

In practice, that shift does not require a complete reinvention of how teams build software.

Most organisations begin by moving basic transparency closer to where changes enter the system. That can be as simple as allowing developers to trigger scans from their console, and wiring the same checks into their CI pipeline so they run automatically on every pull request or build.

When that happens, the discussion changes. Instead of discovering, at the end, that a dependency brings an unexpected licence, or that a new component introduces a cryptographic function that needs review, these questions appear when the change is still small and recent. Developers do not need to become compliance experts; they just need clear, timely signals about what might matter.

This is the role tools like SCANOSS play in our own work and with our customers. A scan over a source tree can identify open source components, licences, and cryptographic patterns. The same capability, embedded in CI, can run whenever code is updated. Results show up where teams already look highlighting what is new or unusual. Over time, that creates a more accurate, living inventory of what is actually running in your environment, instead of a snapshot assembled under pressure.

None of this removes the need for governance or security teams. It reshapes their work. Instead of chasing missing information at the end of a project, they receive a more continuous flow of evidence as software evolves. They can focus on policy, guidance, and exception handling, rather than repeatedly sending requests back into the organisation asking “what is this, and who added it?”

The same pattern applies to AI governance, export controls, provenance, and other areas where expectations are tightening. Manual policing does not scale. What does scale is a shared understanding that certain questions should be answered as early as possible, with systems doing most of the collection and humans doing the interpretation. That is where open datasets, machine-readable outputs, and simple APIs make a real difference: they allow compliance signals to travel at the same speed as the code.

If anything, this evolution looks similar to what happened with design systems. Once design rules were encoded into components and libraries, consistency no longer relied on someone checking each screen; it became a property that teams inherited by default. Compliance can move in the same direction. Instead of acting as a gate at the end, it becomes a background structure that keeps everything aligned while work is in motion.

So the question is how to make compliance ordinary — embedded, continuous, and largely unremarkable. When the right information appears at the right time, organisations can move quickly without losing control, and compliance becomes something generated as you go.

In that sense, seamless compliance is not a symbol of bureaucracy. It is a sign of software maturity, the point at which speed and responsibility stop pulling in opposite directions, and trust becomes a built-in feature of how work gets done.