Appearance
Journey: Framework Adoption to Statement of Applicability
Preparing for certification, from a decision to adopt through to a Statement of Applicability an assessor can read before fieldwork begins.
Fictional example using an ISO 27001-style structure for illustration. It shows how OrviQ handles adoption and applicability; it is not a statement about any particular certification requirement.
The objective
A bank is seeking information security certification for its payments platform. The standard contains 93 requirements.
Week 1 — Prerequisites
Three things must exist before adoption produces anything meaningful.
1. The inventory. 63 systems in the payments environment are registered in Assets & Inventory with owners, custodians, environment, criticality and data classification.
2. The declared scope. SCP-2026-0007 — Payments Platform Production:
| Field | Value |
|---|---|
| Purpose | certification |
| Type | population |
| Target type | mixed |
| Owner | Head of Payments Technology |
| Members | 63, effective-dated from 1 January |
3. The framework in the library. Loaded by catalogue import.
Name the scope for the boundary, not the project
"Payments Platform Production" survives the certification project. "ISO Certification 2026" does not, and the scope will still be needed for surveillance visits three years later.
Week 2 — Adoption
Framework Adoption FAD-2026-0004:
| Field | Value |
|---|---|
| Framework | The information security management standard |
| Scope | SCP-2026-0007 |
| Purpose | Certification |
| Owner | Head of Information Security |
| Lead assessor | Senior Compliance Analyst |
Adoption seeds 93 applicability records, all Under Review, governance state draft.
The honest starting state
"We govern this body of requirements here, and we have not yet determined which of them apply."
That is very different from the two convenient lies available at this moment: assuming everything applies, or assuming nothing does.
SoA at this point: 93 obligations, 0 applicable, 0 not applicable, 93 under review. Not ready for anything.
Weeks 3 to 8 — Applicability determination
The lead assessor works through all 93.
A representative Applicable decision: no justification required; the obligation simply applies.
A representative exclusion:
"The payments platform is operated exclusively from two secured facilities. No remote operational access is permitted to in-scope systems; remote administrative access is technically blocked at the network boundary and evidenced under the network security clause. Confirmed with the Head of Platform Operations, February 2026."
A second exclusion:
"No development activity occurs within this scope. All change is delivered by the group engineering function under separate scope
SCP-2026-0009, where this clause is Applicable and addressed byCTL-2026-0052."
The second justification is stronger than the first
It says where the obligation is met, under which scope, by which control. An assessor reading it has no follow-up question.
AI assistance drafts several justifications. The analyst edits every one — the drafts state that something does not happen; the analyst's versions state where it does happen instead. See AI Applicability Rationale.
Review. The Compliance Manager reviews each decision. She rejects one proposed exclusion:
"Provider responsibility does not remove our obligation. This is Applicable, discharged through provider assurance evidence."
Revised to Applicable and approved.
Final position: 81 Applicable, 12 Not Applicable, all approved.
A maker-checker chain that never rejects anything is not a control
One rejection out of 93 decisions. That rejection prevented an obligation being silently excluded on a reasoning error that would very likely have been challenged at assessment.
Weeks 9 to 16 — Mapping
Only the 81 applicable obligations are mapped. The 12 exclusions need no controls.
Determining applicability before mapping saves real work
Mapping first would have meant mapping controls to 12 obligations that were never going to apply — and then explaining to an assessor why excluded obligations have controls against them.
Control discovery plus AI proposal produces 214 proposed mappings across the 81 obligations.
Review by the Compliance Manager:
| Outcome | Count |
|---|---|
| Approved as proposed | 78 |
Adjusted then approved, mostly equivalent reduced to subset | 61 |
| Rejected | 44 |
Recorded as no_match | 31 |
Obligations with no mapping after review: 14. Each becomes a finding — these are the genuine control gaps the exercise was for.
Weeks 17 to 24 — Evidence and controls
Fourteen findings produce fourteen action plans. Eleven are resolved by mapping existing controls that had not been proposed; three require new controls to be built.
Expected evidence is defined for the mapped controls, and evidence is gathered.
Week 25 — The SoA, first read
| Metric | Value |
|---|---|
| Total requirements | 93 |
| Applicable | 81 |
| Not applicable | 12 |
| Under review | 0 |
Implementation context distribution:
| Value | Count |
|---|---|
| Implemented via Controls | 78 |
| Planned / Unmapped | 3 |
| In Progress | 0 |
| Not Applicable | 12 |
The three Planned / Unmapped are the new controls still being built, each with a finding and an action plan against it.
Three unmapped obligations at stage 1 is a better position than a claim of full implementation
An assessor will ask about them, and the honest answer is available: the requirement applies, no control is yet mapped, and there is a finding and an action plan with a named owner and a due date.
A statement claiming full implementation that fieldwork then contradicts is a much worse position.
Week 26 — Pre-assessment checks
The five checks before exporting for the assessor:
| Check | Result |
|---|---|
| Every Under Review row resolved | Yes, 0 remaining |
| Every exclusion approved | Yes, 12 of 12, governance state approved |
| Justifications read as an assessor would | Two rewritten to name where the obligation is met instead |
| Planned / Unmapped rows explicable | Yes, 3, each with a finding and action plan |
| Export with the as-of date set | Done |
Stage 1 assessment
The assessor reads the SoA before fieldwork.
Questions asked: the three unmapped obligations, and two of the twelve exclusions.
On the exclusions: both justifications named a person and a date, and one named the alternative scope and control. Neither was challenged further.
On the unmapped obligations: the findings and action plans were shown, with owners and dates. The assessor recorded them as known gaps under active remediation rather than as nonconformities.
Month 14 — Surveillance
The certification body returns and asks how the control set has changed.
Two views are produced:
| View | Approved mappings | Notable |
|---|---|---|
| As of the certification date | 187 | Includes 14 mappings to controls since decommissioned |
| Current | 194 | Includes 21 mappings created since |
The difference is a change record, not a discrepancy. Each retirement carries a date and a reason; each addition carries a proposer, a reviewer and an approval date.
The follow-up question — "why did CTL-2026-0033 stop addressing this clause?" — is answered from the mapping's own retirement record.
See Historical Reconstruction.
What the journey demonstrates
| Principle | Where |
|---|---|
| Scope before assurance | Week 1 — inventory and scope precede adoption |
| The honest starting state | Week 2 — 93 under review, not 93 applicable |
| Only approved exclusions are authoritative | Weeks 3 to 8 |
| Mandatory justification, and what good looks like | Weeks 3 to 8 |
| A chain that rejects something is a working chain | Week 8 |
| Applicability before mapping saves work | Week 9 |
| AI drafts; the human owns what it says | Weeks 3 to 8 |
| Unmapped obligations are visible, not hidden | Week 25 |
| The SoA is derived, so it cannot drift | Week 25 |
| Historical reconstruction answers surveillance questions | Month 14 |