What are Compliance Shapes?

Should developers be empowered to deploy their own changes, or should changes go through central approval?

Should employees use corporate-managed devices, or can they bring their own?

Should your company host the service, or should customers host it themselves?

Should you accept and process a broad range of customer data, or deliberately minimise what the service can receive?

Should governance happen through formal committees, or through clearly accountable leaders embedded in the business?

There isn’t necessarily a right answer to these questions.

But the answers have consequences.

They shape your risks, responsibilities, policies, controls, processes, evidence and ultimately what good compliance should look like for your company.

We call these decisions Compliance Shapes.

Compliance Shapes are design decisions

There’s a lot of information you need to understand a company’s compliance program.

What systems does it use?

What data does it process?

Who are its customers?

What regulations apply?

What has it committed to customers?

Where is the system boundary?

What risks does it face?

All of this is important compliance metadata.

Compliance Shapes are a particular subset of that context.

They’re the design decisions within it.

Using AWS is important metadata. It tells us a lot about the infrastructure environment and changes the risks and controls that are likely to matter.

Using AWS GuardDuty is another piece of metadata. It tells us something more specific about how monitoring is implemented.

But neither is really what we mean by a Compliance Shape.

A decision to use a largely serverless architecture rather than operating infrastructure yourself is closer to a shape.

So is deliberately designing a service so customer data doesn’t need to be stored on employee endpoints.

Or giving developers autonomy to deploy software within automated guardrails rather than requiring individual change approvals.

Or making customers responsible for administering their own users rather than taking responsibility for access administration on their behalf.

These are deliberate choices about how the company, product or service is designed to work.

And they have consequences that flow through the compliance program.

There could be thousands of Compliance Shapes

If you took this idea to its logical extreme, you could probably identify thousands of design decisions that influence compliance.

That wouldn’t be particularly useful.

In practice, we’re interested in roughly the 20–30 most consequential decisions.

These are the decisions where choosing one approach over another materially changes how you should think about risks, responsibilities, controls or the way compliance operates.

We think of them across two broad groups:

Product and Service Shapes describe how you’ve designed what you provide to customers and the responsibilities you’ve chosen to take on.

Operating Shapes describe how you’ve designed the organisation and the way people work internally.

Together, they create the company’s overall Compliance Shape.

Product and Service Shapes

Product and Service Shapes define important boundaries around what you’re providing and what responsibility you’re accepting.

Some of the major dimensions include:

Hosting responsibility

Provider-hosted ↔ Customer-hosted

Do you operate the environment customers rely on, or provide software that customers operate themselves?

That decision fundamentally changes the system boundary and the responsibilities on each side.

Data exposure

Broad data collection ↔ Data minimisation

Does the service allow customers to upload or process broad categories of information?

Or is the product deliberately designed to minimise the data it receives?

Minimisation can reduce the inherent risk of the service rather than adding controls later to manage risk you’ve chosen to accept.

Availability responsibility

Committed availability ↔ Best-efforts availability

Is availability something customers are contractually or operationally relying on you to provide?

A business-critical platform with meaningful uptime commitments has a different shape from a service where interruptions have limited customer impact.

Extensibility

Closed service ↔ APIs and integrations

APIs can materially increase the value of a product.

They can also expand its attack surface, dependencies, authentication requirements and responsibility for how systems interact.

The choice involves customer value on one side and additional risk and responsibility on the other.

AI functionality

Conventional functionality ↔ Material AI functionality

Does AI perform a peripheral supporting function, or do customers materially rely on AI-generated decisions, outputs or actions?

As that reliance increases, different risks, expectations and dependencies become relevant.

Customer administration

Customer-managed ↔ Provider-managed

Do customers administer their own users, permissions and configuration?

Or does your organisation take responsibility for some of that administration?

Responsibility for outcomes

Customer-directed use ↔ Provider responsibility for outcomes

Is the customer responsible for what they do with the software?

Or does the nature of the service create explicit or implicit expectations about the accuracy, reliability or outcome of what the system produces?

Service standardisation

Standardised ↔ Customer-specific

Does every customer receive essentially the same service?

Or do you configure, customise or operate parts of it differently for individual customers?

These decisions aren’t made purely for compliance reasons.

They’re product decisions.

They involve customer value, commercial strategy, risk appetite, customer expectations, available resources and the responsibilities the company is willing to accept.

But they can materially change what compliance needs to address.

Operating Shapes

Operating Shapes answer a different question:

How have we chosen to run the organisation?

Some of the most consequential include:

Access

Distributed ↔ Centralised

Do individual system owners administer access, or is identity and access management centrally controlled?

Change management

Traditional approval ↔ Agile ↔ DevSecOps ↔ Empowered developers

Does every production change require explicit approval?

Or can developers deploy independently within defined technical and procedural guardrails?

Infrastructure

Self-managed ↔ Managed/PaaS ↔ Serverless

How much responsibility does the organisation retain for operating the underlying infrastructure?

Workforce

Office ↔ Hybrid ↔ Remote-first

Where do employees work, and what physical and technical assumptions can the company reasonably make about their environment?

Devices

Corporate managed ↔ BYOD

Does the organisation tightly control endpoints, or design its environment so unmanaged endpoints can be used within acceptable risk?

Production access

Standing ↔ Just-in-time / elevated

Do people retain privileged production access, or receive it temporarily when required?

Risk management

Periodic ↔ Continuous

Is risk primarily identified through formal periodic assessments, or continuously through the company’s operating processes?

Vendor management

Central procurement ↔ Distributed ownership

Does a central function select and oversee vendors, or do teams own the systems and third parties they introduce?

Incident response

Central security team ↔ Engineering-led

Does a dedicated security function lead incidents, or are the teams closest to the affected systems primarily responsible for responding?

Governance

Formal committees ↔ Embedded operational ownership

Does governance happen through boards and committees, or through accountable leaders embedded in normal operations?

Again, neither end of these spectrums is inherently better.

The important question is whether the chosen shape actually works.

The objective usually stays the same

This is where Compliance Shapes become particularly useful.

The underlying compliance requirement or control objective often doesn’t change.

Take change management.

At a high level, you want changes to be appropriately designed, tested, authorised and deployed so they don’t introduce unacceptable risk.

There are many ways to achieve that.

A large organisation might have a formal, centrally governed process involving tickets, testing, approvals, segregation of duties and scheduled releases.

A SaaS company might instead empower developers to deploy changes themselves, with peer review, automated testing, code scanning, vulnerability scanning and CI/CD providing the guardrails.

The objective is similar.

The shape is different.

That shape then influences:

Requirement / objective → Compliance Shape → risks and control design → implementation → evidence

And the consequences aren’t limited to controls.

Shapes can flow through policies, risk assessments, responsibilities, processes, evidence, monitoring and even how an audit should be performed.

A more traditional shape isn’t necessarily more rigorous

This is an important point.

We worked with a software company that needed to release features constantly.

Shipping quickly wasn’t just an engineering preference. Customers were relying on the company to deliver a significant pipeline of new functionality.

A heavily gated change process was actually creating problems.

Changes were accumulating while they waited to be released. Releases became larger. More things changed at once. And the risk that a release would negatively affect customers increased.

So the company moved towards a different shape.

Developers had more autonomy, but the deployment pipeline had automated tests, code scanning, vulnerability scanning and other gates that changes had to pass before reaching production.

That shape better matched the way the company needed to operate.

In fact, requiring more individual human reviews and approvals could have made the process less reliable.

People have busy days. Reviewers get overloaded. Attention varies. When you’re deploying multiple times a day, a process highly dependent on repeated human approvals can eventually become a box-ticking exercise.

The supposedly less rigorous shape can sometimes be the more robust one.

But the modern shape isn’t automatically better either

The opposite is equally important.

We worked with another company where developers didn’t want formal processes around deploying changes.

The CTO did.

Changes were reaching production that didn’t work properly, customers were being affected, and it was getting in the way of the company’s objectives.

The CTO effectively wanted the audit process to help establish greater discipline around change management.

In that environment, simply declaring the company to have an “empowered developer” shape wouldn’t solve anything.

The existing way of operating wasn’t adequately managing the risk.

This is why Compliance Shapes aren’t about letting everyone work however they want.

A shape has to stand the test of practice.

Does it achieve its purpose?

Does it adequately manage the relevant risks?

Does it support the company’s objectives?

Does it allow the company to meet its commitments?

If not, something needs to change.

Shapes aren’t controls

An empowered-developer model can work extremely well.

It can also fail badly.

Imagine hiring a relatively inexperienced developer and immediately giving them unrestricted ability to deploy directly into production.

If the surrounding system doesn’t have appropriate guardrails, they can introduce a change that causes a customer outage.

The problem isn’t necessarily the empowered-developer shape.

The problem is that the shape hasn’t been adequately implemented.

The same is true at the other end of the spectrum.

You could have multiple required approvals for every production change.

On paper, that looks highly controlled.

But if approvers receive so many requests that they routinely approve them without meaningful review, the shape isn’t achieving its purpose either.

The shape tells you how you’ve chosen to operate. The controls make that shape work.

Often it’s the combination of several controls that makes a particular shape effective.

That’s why evaluating a compliance program purely by looking for individual controls can miss the bigger picture.

Governance is another good example

Consider an early-stage startup.

A conventional interpretation of governance requirements might lead someone to decide the company needs a formal board or security committee.

You can create one.

You can schedule quarterly meetings.

You can write minutes.

And you can tick the box.

But if the structure exists primarily for compliance, it may provide less meaningful oversight than the way the company actually operates.

In a small founder-led company, governance might work more effectively through clearly defined leadership responsibilities, frequent communication between the relevant people, visibility of risks and issues, and direct executive involvement in important decisions.

As the company grows, that shape may stop working.

More people become involved.

Information becomes distributed.

Founders have less visibility.

Responsibilities become more specialised.

At that point, more formal governance structures might become the better shape.

Compliance Shapes can change as the company changes.

What determines the right shape?

There isn’t a universal formula.

For Product and Service Shapes, some of the biggest considerations are:

the product vision;

customer value;

customer expectations;

the sophistication and resources of the customer;

commercial requirements;

security and privacy risk;

regulatory expectations;

support requirements;

the amount of responsibility the provider wants to accept.

Sometimes taking on more responsibility creates more value.

Offering an API is a good example.

It may increase the risk surface, but the integration capability may be fundamental to the value customers receive.

Other times, deliberately reducing responsibility makes the service easier to secure and easier for customers to adopt.

For Operating Shapes, the considerations tend to be more internal:

company size and maturity;

available resources;

risk level;

scalability;

cost;

team structure;

employee capabilities;

preferred ways of working;

automation philosophy;

customer expectations.

An early-stage startup may rationally choose a very lean operating shape.

There are fewer people. Founders have direct visibility. Communication is easier. The inherent organisational complexity is lower.

As the organisation grows, the same shape may no longer work.

More formalisation, separation of responsibilities and layers of control may become necessary.

The goal isn’t to choose the shape that looks most sophisticated.

It’s to choose the shape that works.

Shapes have to reconcile

Individual Compliance Shapes don’t exist in isolation.

They form a system.

Suppose a company handles highly sensitive customer information.

Employees can freely download that information.

The company allows BYOD.

Endpoints aren’t managed.

There are limited technical restrictions on what happens to downloaded data.

At the same time, the company has made strong commitments to customers about protecting their information.

There is tension between those shapes.

That doesn’t mean BYOD is inherently non-compliant.

A different company might allow BYOD while keeping customer information entirely inside controlled cloud applications, preventing local downloads, enforcing strong identity controls and limiting what unmanaged endpoints can do.

Same headline shape.

Very different risk.

This is why the objective isn’t to evaluate each design decision in isolation.

The Compliance Shapes need to reconcile with each other, the risks, and what the company has committed to achieve.

This is where compliance theatre comes from

If you don’t consciously understand these shapes, it’s very easy to start with a generic compliance template and work backwards.

The template says you need a quarterly committee.

So you create a quarterly committee.

It says changes require approval.

So you create a ticket that someone approves.

It assumes corporate-managed devices.

So the policy says devices are centrally managed even though that’s not really how the company operates.

Eventually there are two versions of the organisation.

There’s the way people actually work.

And there’s the way the compliance program says they work.

That’s compliance theatre.

The problem isn’t necessarily that the controls are too weak.

Sometimes they’re unnecessarily strong, but in ways that don’t meaningfully reduce risk.

Sometimes they’re simply aimed at the wrong problem.

Good compliance should strengthen how the company actually operates, not create a parallel version of the company for the auditor.

Compliance Shapes should be conscious decisions

Not every company consciously chooses its Compliance Shapes.

Often they just emerge.

A founder gives everyone administrator access because there are four employees.

Engineering starts deploying directly because it’s faster.

People use their own laptops because nobody has implemented device management.

Risks are discussed informally because everyone sits in the same room.

None of those decisions is necessarily unreasonable at that stage.

The problem comes when an accidental way of working becomes a permanent operating model without anyone reconsidering whether it still makes sense.

A useful compliance program makes these choices explicit.

How do we want access to work?

How do we want changes to work?

What responsibility do we want for customer data?

What availability are we actually promising?

What should happen on employee devices?

Who owns risk?

How do we want governance to work?

Then you can design controls around the answers.

That can produce compliance that’s both less burdensome and more meaningful.

Why Compliance Shapes matter for agentic compliance

This is also where AI starts to change compliance in a more interesting way.

AI already knows what change management is.

It knows SOC 2.

It knows ISO 27001.

It knows common security practices.

It can produce a perfectly reasonable access-control policy or change-management procedure in seconds.

The harder problem is knowing which reasonable answer fits this company.

That’s where Compliance Shapes become important.

Tell an AI agent:

We use an empowered developer model. Developers deploy frequently through CI/CD. Peer review is enforced through GitHub. Automated testing and security scanning gate deployments. We deliberately don’t operate a traditional change advisory board.

That context doesn’t just influence one control.

It can influence the policy the agent writes.

The controls it defines.

The risks it identifies.

The evidence it looks for.

The exceptions it flags.

The recommendations it makes.

The way it answers a customer security questionnaire.

The information it prepares for an auditor.

Humans are generally pretty good at conceptually understanding this context.

We’re less good at remembering every single place it should influence a compliance program.

An AI agent can carry a design decision through hundreds of downstream compliance decisions.

That’s one of the areas where we think agentic compliance becomes particularly interesting.

Compliance Shapes and the Compliance Brain

Compliance Shapes form part of what we call a company’s Compliance Brain.

The Compliance Brain is structured context that helps an AI agent understand the company well enough to operate its compliance program intelligently.

It includes more than shapes.

It needs to understand things like:

system scope;

customers;

data;

regulatory requirements;

contractual commitments;

technology;

responsibilities;

compliance objectives;

evidence sources.

Compliance Shapes capture something slightly different.

They capture the consequential design choices within that environment.

For practical purposes, we’re developing an authoritative set of roughly 20–30 Compliance Shapes that capture the decisions we believe have the greatest downstream influence on a compliance program.

The purpose isn’t to model every possible nuance of a company.

It’s to capture enough of the important decisions that a human, consultant, auditor or AI agent can understand how compliance is supposed to work here.

The hierarchy matters

One way to think about the relationship is:

Company context and commitments

↓

Compliance Shapes

↓

Risks and control design

↓

Implementation

↓

Evidence

The requirement or objective often remains relatively stable.

The shape determines how the company chooses to achieve it.

The controls make the shape work.

The implementation puts those controls into practice.

And the evidence demonstrates whether they actually operated.

Product and Service Shapes can reach further upstream because they can change the scope, responsibilities and even which objectives are relevant in the first place.

That’s why understanding the company’s shapes early can have such a large effect on everything downstream.

Your compliance program should have a shape

For years, compliance automation has largely worked by making companies fit increasingly good templates.

That has had enormous benefits.

But a template can only go so far.

Every company already has a shape.

The question is whether you’ve consciously designed it, whether the pieces work together, and whether your compliance program reflects it.

There isn’t one correct way to govern a company.

There isn’t one correct way to deploy software.

There isn’t one correct device model, access model, infrastructure model or risk-management model.

There are different designs that can achieve the same objective.

Some will fit your organisation better than others.

And some will work better in practice than approaches that look more rigorous on paper.

The role of good compliance is to understand those choices, test whether they actually manage the risks and requirements that matter, and design the program around them.

Your compliance program should fit your company. Not the other way around.