Compliance - Your frameworks

Choosing a framework: why enabling it is deliberately yours alone, and what Lex does with it once it's on.

Deliberately yours alone

Which frameworks apply to your organisation is your decision.

You can ask Lex, the compliance sidekick, for a second opinion — but Lex can't enable a framework on your behalf. Most of what Lex does saves you the busywork of reading and drafting; adding a framework is the one step kept out of its reach on purpose.

Typical workflow

Your frameworks live under Compliance → Frameworks, in two parts: the ones you've enabled, and the catalogue of everything else available to you.

Reviewing what you've enabled

The enabled list is the quick read on what you've committed to. Removing a framework only takes it out of this project's catalogue — existing assessments and scores are kept, and come back with it if you enable it again later.

Opening an enabled framework gives you a summary of where you stand: how much of it your existing evidence already covers, your current maturity, and the gaps that remain.

Enabling a new one

Enable a framework from the catalogue and you get an assessment to score against straight away, along with that same starting picture:

how much of the framework your existing evidence already covers
your current maturity
the specific gaps

Lex then drafts a target maturity and a review cadence for someone with the authority to approve them.

Some frameworks need a licence before their content can be used, and the catalogue marks those clearly.

Bringing your own standard

If you're held to a standard that isn't in the catalogue — an industry checklist, a customer's supplier questionnaire, your own internal control set — you can add it as a custom framework and assess against it exactly like any other.

The format is a single JSON file

A framework is described by one JSON file listing its structure and its controls. That is the only way in: there is no spreadsheet or questionnaire importer, and deliberately so. Turning your source document into that file is the step where the judgement lives — deciding what is a section, what is a scoreable control, and what each control is really asking for.

The good news is that this is work an AI does well, and you don't have to explain the format to it. Everything needed is published from the product itself:

From the app. Compliance → Frameworks → Create or Import Framework gives you the example format to download and a ready-made prompt to copy. Hand both to whichever assistant you use, along with your standard, then import the JSON it returns.
From your own agent. Once connected over MCP it can read the whole contract itself — the schema, the rules a schema can't express, and the worked example.
From Lex, the compliance sidekick, which reads the same contract, so you can hand it the standard and review what it drafts.

All three get identical instructions, so it makes no difference whose assistant does the work. The example file carries the conversion steps inside itself, so an assistant given only that file still has what it needs.

Check it before you commit to it

A draft can be checked without importing anything. The check reports what the framework contains and flags the things that are legal but usually mistakes — a control that belongs to no section, a duplicated identifier, a baseline applied to everything or to nothing, controls left unmapped where the source did offer a reference, or requirement tiers recorded in a way that will never affect maturity. These are worth reading: none of them stops an import, and each is easier to fix before people start assessing against it.

An agent proposes the import rather than performing it. Someone with the authority to accept it reviews the draft and approves, matching how every other suggestion is handled.

Three things worth getting right

Licensing is your declaration

You state what the source permits: whether it's public, and whether the file carries the standard's own wording or only your summaries of it. A framework whose text is licensed stays private to your organisation and asks for an acknowledgement before use — so declare it accurately.

The wording of a requirement is the source's, not the assistant's. Control titles are copied across word for word, because those are the words people are assessed against. An assistant that tidies the grammar or writes a requirement where the source had none produces something that reads exactly like the rest of the standard while being nobody's actual obligation. Interpretation belongs in the mapping decisions — which section a control sits in, what it maps to, which tier it is — and those are all visible and changeable. The requirement text is not the place for it.

That is different from a licence obliging you to summarise. Where you may not reproduce the standard's wording, writing your own summaries is a deliberate choice you record — say the file carries identifiers and your summaries rather than the full text, and the framework is labelled that way wherever it appears. What the rule forbids is the silent kind: a requirement quietly reworded or invented while the file still claims to carry the source's own words.

Cross-framework credit is decided during the conversion. Scoring a control once and having that answer count everywhere it legitimately applies depends on each control being tied to a single shared reference point. Source documents usually give those references per section rather than per control, so the assistant chooses which one best fits each control, from the references the source itself supplies. Where a section offers only one, there is nothing to decide.

A control can be left unmapped where none of the references genuinely fits, and the framework is still fully usable — coverage, maturity and gaps all report normally. It simply won't share credit with your other frameworks until it's mapped, so the requirement list marks those controls and the pre-import check counts them.