DevSecOps · Compliance · Delivery

Compliance Frameworks Are Not a Competition, But Here Is What They Actually Cost Your Delivery Team

  • DevSecOps · Compliance
  • 2026-05-25
  • blog
Compliance Frameworks

Somebody asked me the other day which compliance framework is the hardest.

It is a stupid question, but I have been thinking about why it keeps coming up.

Executives want to know which box to tick. Delivery teams want to know how much paperwork they are about to drown in. Consultants want to sell you a "compliance transformation" that somehow costs more than the software you are trying to ship.

None of those conversations actually help a delivery team.

So here is the real answer, based on what the AppGenie Compliance MCP server actually knows about four frameworks: what each one expects from a project team, which ones will slow you down, and which ones are basically free if you are already doing competent engineering.

The Raw Numbers

Here is the compliance burden comparison across ISO 9001, ISO 27001, IRAP and FedRAMP, straight from the indexed standards:

Framework Register Entries Evidence Classes Risk Records Total
ISO 9001 1 3 0 4
IRAP 2 6 1 9
ISO 27001 4 7 1 12
FedRAMP 3 12 2 17

FedRAMP is the biggest. ISO 9001 is the smallest. Nobody is surprised.

But raw obligation count is a trap. A delivery team that tries to "comply with FedRAMP" by counting to 17 and building a spreadsheet for each one is going to die a slow death. That is not how this works.

What These Numbers Actually Mean for Your Team

ISO 9001 -- Four obligations. Basically a free hit if you have a CI/CD pipeline.

ISO 9001 wants delivery evidence, change traceability, and artefact version traceability. If you are doing continuous delivery with any kind of automated pipeline, you already have all three. Your build pipeline produces delivery evidence. Your version control produces change traceability. Your artefact registry produces version traceability.

If you are not doing those things, ISO 9001 is the cheapest possible excuse to start.

This is the framework you use when you need to prove you are not a cowboy operation. It asks very little. It gives you a certificate that unlocks procurement doors. There is no reason to struggle with this one.

IRAP -- Nine obligations. Real security, reasonable ask.

IRAP wants delivery evidence, change traceability, artefact version traceability, change control evidence, artefact integrity hashes, patch and vulnerability remediation evidence, and a vulnerability remediation risk record.

This is the Australian Government's security framework. It is security-focused without being sadistic. The evidence classes are things a competent team should already be producing. Integrity hashes on artefacts? Your package manager does that. Change control evidence? Your pull request process does that. Vulnerability remediation? You should be doing that anyway.

IRAP is harder than ISO 9001, but it is also more useful. It proves you can handle sensitive data in a government context. The evidence burden is manageable if your delivery discipline is already decent.

ISO 27001 -- Twelve obligations. The full information security management system.

ISO 27001 adds asset registers, asset ownership records, retention schedule mapping, protected audit evidence, and dependency vulnerability scanning on top of the common evidence classes.

This is where the pain starts.

Asset registers are not technically hard, but they are an organisational problem. You need to know what you have, who owns it, and what it does. That is a discovery exercise across the entire organisation, not just the delivery team.

Retention schedule mapping means you need to know how long you keep audit evidence and what destroys it. That is a legal conversation with your data governance people.

Dependency vulnerability scanning sounds like a tooling problem until you realise the scan produces findings and the findings need remediation risk records and the risk records need owner sign-off. That is a process loop, not a checkbox.

ISO 27001 is the first framework on this list that genuinely requires organisational buy-in beyond the delivery team. You cannot code your way out of asset registers and retention schedules.

FedRAMP -- Seventeen obligations. This is the heavyweight.

FedRAMP takes everything ISO 27001 requires and adds baseline configuration evidence, developer configuration management evidence, supplier and component provenance evidence, deployed version monitoring evidence, supply-chain risk records, and integrity failure incident records.

Seventeen obligations, twelve of which are evidence classes that must be continuously produced, not snapshotted once.

Supplier provenance is a particular bastard. You need to know where every dependency came from, who wrote it, whether its supply chain is secure, and whether you can trust it. In a world where most projects depend on multiple layers of open source transitive dependencies, this is not a technical problem you solve in a sprint. It is a procurement, licensing, legal and engineering problem that takes months to mature.

Deployed version monitoring means you cannot deploy something and forget about it. You need continuous evidence that what is running is what you think is running, and that it matches your configuration baseline.

FedRAMP is the only framework on this list that forces you to solve runtime configuration drift as a compliance requirement. That is expensive.

What a Smart Delivery Team Does With This Information

Start with the common evidence classes.

Every single framework on this list requires delivery evidence, change traceability, and artefact version traceability. If you build those three things into your pipeline once, they are automatically satisfied for every framework you pursue later.

Build the common layer first. Do not framework-hop without it.

Understand the difference between registers and evidence.

Registers are lists. Evidence is proof.

A delivery register is a list of things you delivered. Delivery evidence is the proof that you delivered them correctly. The register is administrivia. The evidence is engineering. Spend your energy on evidence automation, not register management.

Do not confuse technical difficulty with compliance difficulty.

ISO 9001 is technically trivial but opens procurement doors.

FedRAMP is technically demanding and opens US federal procurement doors.

Do not pursue FedRAMP because you want to be the best. Pursue it because you need to sell software to the United States federal government. If you do not need that, FedRAMP is a seventeen-obligation tax on your delivery velocity with no return.

Treat compliance evidence as a byproduct of engineering, not a separate activity.

The worst teams build software and then hire somebody to retrofit compliance evidence. That is backwards and expensive.

The best teams design their pipelines so that every deployment produces compliance evidence as a side effect. The artefact is hashed, the hash is stored, the deployment is logged, the change is traceable to a work item, the work item is traceable to a requirement, and the requirement is traceable to a control.

If you are not building that pipeline, everything you read above is going to hurt.

The AppGenie Compliance MCP Server: Stop Guessing, Start Querying

Here is the problem with everything I just wrote: it is all correct, but it is useless unless you can actually query the standards directly when you need to make a decision.

We got tired of watching teams drown in spreadsheet compliance. So we built something for ourselves that turned out to be useful for everybody else.

The AppGenie Compliance MCP server is our internal compliance knowledge engine. It has 89 documents and 2,224 clauses indexed across four frameworks -- ISO 9001, ISO 27001, IRAP and FedRAMP. You can query it, compare frameworks side by side, overlay requirements, and get answers with citations in seconds. Not hallucinations. Not a consultant's opinion. The actual indexed standards.

When I say "FedRAMP requires 12 evidence classes" above, it is not because I memorised them. The MCP server returned that data. The evidence classes are mapped. The register requirements are structured. The output is usable.

We use this thing every day to:

  • Compare framework burdens before a client picks a target, so they do not spend six months pursuing the wrong one
  • Identify overlapping evidence classes so teams build the common layer once and satisfy multiple frameworks with the same pipeline
  • Spot missing controls before an audit, not during it, when the fix is still cheap
  • Automate compliance answers instead of having a human dig through 2,200 clauses by hand every time a question comes up

The AppGenie Compliance MCP server is not a replacement for a human compliance officer. It is a force multiplier for one. If your team is trying to figure out which framework to target, or how to produce evidence without losing delivery velocity, we can show you how this thing turns a discovery project into a query.

Drop us a note if you want a walkthrough.

The Bottom Line

Four frameworks. Four different burden profiles. One pattern that works for all of them.

Automate the common evidence layer. Understand what each framework actually demands beyond the common layer. Pursue the framework that matches your procurement reality, not your ego.

If you are selling to Australian government, IRAP is your target.

If you need a quality management certificate to get in the door, ISO 9001 is trivially achievable.

If you need information security management system certification, ISO 27001 is the standard and it requires organisational commitment beyond the engineering team.

If you are selling to the US federal government, FedRAMP is unavoidable and it will eat your delivery capacity for months.

Pick the right one. Automate the evidence. Query the standards instead of guessing them.