Unified control library: how to build one common control framework for every standard

You passed ISO 27001 last year. Now an enterprise customer wants a SOC 2 report, a financial-services prospect has sent a DORA questionnaire, and your spreadsheet already holds three versions of "review user access". Each audit asks for the same evidence in a different shape. A common control framework stops that before the fourth standard arrives.

This guide is for heads of compliance, GRC leads and CISOs at UK B2B tech firms with 25 to 250 staff that hold one certification or report and have just been asked for a second. It covers what a unified control library is, what each control record holds, how to choose a spine, a step-by-step build, and how to keep the library current.

What is a unified control library?

A unified control library, also called a common control framework, is a single set of controls written once in your own words. Each control has an owner, a frequency, its evidence and a test, and each references every framework requirement it satisfies by ID. The payoff is implementing, testing and evidencing each control once for every audit.

The library sits between your standards and your operations. Standards say what must be true. The library says what your firm does to make it true, who does it, how often, and how you prove it.

If ISO 27001 is your first standard, our ISO 27001 hub covers the basics. This page assumes you already run an information security management system and now need it to serve more than one audit.

How is a common control framework different from a crosswalk?

A common control framework is a set of controls you own and run. A crosswalk is a table that shows where requirements in two or more standards overlap. The crosswalk tells you which requirements look alike; the library is what you actually operate, test and evidence. You can build one without buying a crosswalk or a framework.

Three things a unified control library is not:

• Not a crosswalk. A crosswalk compares requirements. It has no owners, no evidence and no tests.
• Not a framework you buy. A published catalogue can be your starting point, but the library describes your firm, so the wording, owners and evidence have to be yours.
• Not a policy set. Policies state intent. Controls are the recurring activities that carry the intent out and leave records behind.

Mapping each new framework onto the library, requirement by requirement, is a separate method, and this guide leaves it out.

What goes in each control record?

Each control record needs eight fields: a control statement in your own words, the objective it serves, a named owner, a frequency, the evidence it produces, a test procedure, its automation status, and the requirement references it satisfies by ID. Together they make the control something you can run, test and hand to an auditor.

Keep the statement short and testable. "Access to production is reviewed quarterly by the system owner, and removals are completed within five working days" can be tested. "Access is managed appropriately" cannot.

A control nobody owns is a sentence, not a control.

Which spine should you build your control library on?

The spine is the structure your controls hang from. You can start from a published catalogue, such as the Secure Controls Framework, NIST CSF 2.0, the CIS Controls or ISO 27001 Annex A, or build your own. Each choice carries licence terms, so check what you may copy, adapt and share before you start.

The SCF suits firms expecting several frameworks, because its domains are broad and it publishes its own mappings to many laws and frameworks. The SCF terms and conditions are strict about derivatives. They say that remixing, transforming or building on the material means you may not distribute the modified version, and that using AI to generate derivative content from SCF material counts as a derivative work. An adapted SCF library can run your controls internally. Publishing it, or putting it in a product, needs a commercial licence.

For most firms that already hold ISO 27001, Annex A is the practical spine. Your team already knows the numbering, the Annex A controls are already in your Statement of Applicability, and a second framework becomes extra references on existing records.

NIST CSF 2.0 suits firms whose customers or board think in outcomes rather than controls. Our NIST Cybersecurity Framework page explains how it is structured.

Whichever spine you choose, the statements in your library should be your own words. That keeps you clear of copyright and makes every control describe your firm, not a textbook.

How do you build a unified control library, step by step?

Build a unified control library in seven steps: inventory every control you already run, normalise the wording, de-duplicate, rationalise, assign owners and frequencies, attach evidence and tests, then reference requirements by ID. Most of the work is in the inventory and de-duplication.

1. Inventory what you run today. Export every control from your ISO 27001 Statement of Applicability, your SOC 2 control matrix, questionnaires you have answered and any platform or spreadsheet. Include the controls engineers run without calling them controls, such as branch protection or backup jobs.
2. Normalise the wording. Rewrite each one as a single testable statement in the same form: who does what, how often, with what record.
3. De-duplicate. Group statements that describe the same activity. Three versions of a quarterly access review become one control with three sets of references.
4. Rationalise. Split controls that bundle unrelated activities, merge ones that are too granular to test separately, and retire any that no requirement or risk needs.
5. Assign owners and frequencies. Give each control one accountable role, then agree the frequency with that owner, not on their behalf.
6. Attach evidence and a test. Name the record each control produces, where it lives, and how anyone checks it operated. Where a system already produces the record, note it as a candidate for automation.
7. Reference requirements by ID. Record every requirement each control satisfies, using identifiers only. Then version the library as 1.0 and treat it as the source your audits draw from.

We recommend doing steps 1 to 4 in a working session with each control owner rather than alone. Owners know which "duplicates" are really two different activities.

How does the control library feed evidence, testing and the Statement of Applicability?

The control library becomes the single source for three things: the evidence you collect, the testing you run and the documents auditors read. Evidence is collected once per control, not once per framework. Internal tests follow each control's test procedure. The ISO 27001 Statement of Applicability becomes a view of the library, filtered to Annex A references.

Evidence collection. Because each control names its record, you collect evidence once per control per period. A single quarterly access-review record can then serve your ISO 27001 surveillance audit and your SOC 2 Type 2 period alike.

Control testing. The test procedure in each record lets you test controls on your own timetable, before an auditor does. ISO 27001 clause 9.1 expects you to evaluate information security performance and the effectiveness of the management system, and our page on monitoring, measurement, analysis and evaluation shows how internal testing supports that.

Audit documents. Your Statement of Applicability records the Annex A controls you apply, why, and whether they are in place. With a library, it is generated from the references rather than maintained as a separate document. Our guide to ISO 27001 documents covers what the Statement of Applicability must contain. A SOC 2 control matrix works the same way, filtered to the Trust Services Criteria instead.

The test of a good library is simple. When an auditor asks for evidence, you look up one control, not three spreadsheets.

How do you keep a common control framework current?

Keep a common control framework current by versioning it, reviewing it on fixed triggers and reviewing all of it at least once a year. The triggers are a new version of a framework you hold, a new regulatory obligation, a material change to your systems, and findings from audits or internal tests.

Version the library. Give the library a version number and keep a change log: what changed, why, who approved it and which references moved. Auditors ask how a control changed during a period, and the log answers them.

Framework changes. The move from ISO/IEC 27001:2013 to ISO/IEC 27001:2022 is the recent example. UKAS set 31 October 2025 as the date by which certification bodies had to complete their clients' transitions. With a library, a transition like that means updating references and adding the few controls that are genuinely new, not rewriting the control set.

Regulatory change. A new obligation, such as DORA for a financial-services customer or the EU AI Act for an AI feature, starts with a requirements review. Many new requirements land on controls you already run as extra references. The rest become new controls with owners from day one.

Annual review. Once a year, read every control with its owner. Check that the statement still matches practice, the frequency still fits the risk, and the evidence still exists where the record says it does.

A library that is only updated at audit time is a snapshot, not a system.

Can you make a control library machine-readable?

Yes. NIST's Open Security Controls Assessment Language (OSCAL) gives you standard, machine-readable formats for a control library. The OSCAL catalog model represents a collection of controls, and the profile model represents a baseline selected from one or more catalogs. Firms automating evidence collection can hold their library as an OSCAL catalog.

The OSCAL project describes the catalog model as designed to represent security and privacy controls in standardised, machine-readable formats. Its profile model notes that organisations may author a profile when they need to define or tailor a set of controls applicable to them.

In practice, the catalog holds your library, and each framework you are audited against becomes a profile over it. If you record owners, evidence and tests as properties in the catalog, tools can check that every control has them and flag the ones that do not. The SCF also publishes its content in OSCAL JSON, which is useful if it is your spine, within the same licence terms.

You do not need OSCAL to start. A well-structured spreadsheet with the eight fields above is a working library. Move to a machine-readable format when you begin automating evidence collection, not before.

What are the common mistakes when building a control library?

The common mistakes when building a control library are copying a framework verbatim, making controls too granular, leaving controls without owners, and keeping controls that map to no requirement or risk. Each one makes the library harder to run and easier for an auditor to question, so the duplication it was meant to remove creeps back.

• Copying a framework verbatim. A statement copied from a standard describes the standard, not your firm, and may breach its licence. Auditors test what you do, so write what you do.
• Too granular. Hundreds of narrow controls each need evidence and a test. If two controls always run together, are owned by the same person and produce the same record, they are one control.
• No owners. A control assigned to "IT" or "the security team" has no owner. Name a role, and make sure the person in it knows.
• Controls that map to nothing. Every control should trace to a requirement, a contract or a risk. If one traces to none, ask why you are paying to run it.
• Frameworks kept in parallel. Building the library, then letting each audit team keep its own spreadsheet as well, recreates the problem.

Treat the library as an engineered system, not a document. That is the difference between preparing for each audit and running a programme that is always ready.

Frequently asked questions