Appearance
Framework Adoption
Where to find it: Regulatory Compliance, then Scope & Applicability (/scope-applicability).
A Framework Adoption is the formal statement that your organisation governs a specific body of requirements, within a specific boundary, for a specific purpose.
Its business reference is FAD-YYYY-NNNN.
The question it answers
"Which standards are we governed by, where, and why?"
That is three questions, and adoption records all three:
| Element | Answer |
|---|---|
| Framework | Which body of requirements |
| Scope | Which declared boundary it applies within |
| Purpose | Why you are governing it here |
Common purposes include certification, internal audit, regulatory filing, continuous monitoring and compliance baseline.
Where it sits
An adoption is the join between what you have and what you are held to.
What an adoption creates
Adopting a framework for a scope seeds an Applicability Record for every requirement in that framework. Each seeded record starts in Under Review with governance state draft.
This is deliberate. The starting state of a newly adopted framework is: "we govern this body of requirements here, and we have not yet determined which of them apply." That is honest, and it is very different from the two convenient lies available to a platform at this moment — assuming everything applies, or assuming nothing does.
What an adoption does not create
Adoption is not implementation
Adopting a framework does not:
- Create controls
- Create evidence
- Assert that anything is implemented
- Change any compliance position
- Modify the library requirements themselves
The library content is untouched. Every tenant decision lives in the adoption's applicability records, which is why two scopes can hold different, simultaneously valid decisions about the same clause.
Adopting the same framework more than once
This is normal and often correct.
A group might adopt an information security standard three times:
| Adoption | Scope | Purpose |
|---|---|---|
FAD-2026-0001 | Payments Production Environment | Certification |
FAD-2026-0002 | Group Corporate IT | Internal audit |
FAD-2026-0003 | Subsidiary Bank Platform | Regulatory filing |
Each carries its own applicability decisions, its own owner and lead assessor, and produces its own Statement of Applicability. A clause may be Applicable in one and Not Applicable in another, each with its own justification and approver — because that is the truth of the situation.
How to adopt a framework
Prerequisite: the scope must already exist. See Scope Registry.
- Open Scope & Applicability.
- Select Adopt framework.
- Choose the framework from your library. If it is not there, bring it in first — see Framework Library.
- Choose the declared scope.
- State the purpose.
- Assign the owner and the lead assessor. These are distinct roles: the owner is accountable for the adoption; the lead assessor drives applicability determination.
- Save. Applicability records are seeded.
Requires compliance.manage or scope.manage.
Adoption fields
| Field | Purpose |
|---|---|
| Business reference | FAD-YYYY-NNNN, immutable, assigned once |
| Framework | The adopted body of requirements |
| Scope | The declared boundary |
| Purpose | Why this framework is governed here |
| Owner | Accountable for the adoption |
| Lead assessor | Drives applicability determination |
| Status | Active or archived |
Archiving an adoption
Archiving stops an adoption being active without destroying it. Applicability records, their history and the Statements of Applicability derived from them remain reconstructable — which matters when an auditor asks about a certification you held two years ago.
Permissions
| Action | Permission |
|---|---|
| View adoptions | compliance.read |
| Create, update or archive an adoption | compliance.manage or scope.manage |
| Record applicability decisions | compliance.manage or obligations.update |
| Approve or reject applicability decisions | compliance.validate or workflow.approve |
Example
A bank is preparing for information security certification of its payments platform.
Before adoption:
- Assets registered: 63 systems in the payments environment
- Scope declared:
SCP-2026-0007 — Payments Platform Production, population type, 63 effective-dated members - Framework in library: the information security management standard, 93 requirements
Adoption: FAD-2026-0004, purpose certification, owner the Head of Information Security, lead assessor a Senior Compliance Analyst.
Immediately after: 93 applicability records, all Under Review, all governance state draft. Statement of Applicability shows 93 undetermined obligations.
Over the following six weeks: the lead assessor works through each requirement, recording Applicable or Not Applicable with justification. The Compliance Manager approves each decision. Final position: 81 Applicable, 12 Not Applicable with approved justifications.
Only now does the mapping and evidence work begin, and only against the 81 that actually apply.
Sequence matters
Determining applicability before mapping saves the effort of mapping controls to 12 obligations that were never going to apply. It also produces a Statement of Applicability an assessor can read before fieldwork begins.
Troubleshooting
"I cannot select my scope." The scope must exist and be active in the Scope Registry.
"No applicability records were created." The framework has no requirements loaded. Check the framework in the library.
"I adopted the wrong scope." Archive the adoption and create a correct one. Do not repoint an existing adoption — the applicability decisions beneath it were made in the context of the original scope, and the historical record should say so.
"Adopt framework is unavailable." You need compliance.manage or scope.manage.