diff --git a/SCOPE.md b/SCOPE.md
index 50903d6..31f0d9b 100644
--- a/SCOPE.md
+++ b/SCOPE.md
@@ -53,14 +53,24 @@ InfoTechCanon artifacts this canon **references rather than absorbs**:
 | `infospace/models/security/` | boundary under review in `SECURITY-WP-0001-T02` |
 | `infospace/models/devsecops/` | boundary under review in `SECURITY-WP-0001-T02` |
 
-Open questions, carried and not assumed:
+Open questions, answered under SECURITY-WP-0001 and no longer carried:
 
-- whether the security and DevSecOps models are better placed here or upstream —
-  the only remaining migration candidates, and neither is urgent;
-- how the small-saas profile's security artifacts relate to this canon;
+- the security and DevSecOps models stay in InfoTechCanon. Both were the only
+  remaining migration candidates and neither cleared the bar of demonstrably
+  helping both canons (SECURITY-DEC-2026-003);
+- the small-saas profile's security artifacts stay whole in InfoTechCanon. A
+  SecurityCanon example references them by id across the federation interface
+  rather than relocating them;
 - the Actor/Subject naming question, analysed in
   [the implications note](docs/260920-actor-subject-implications.md) and decided
-  under `SECURITY-WP-0001-T07`.
+  under `SECURITY-WP-0001-T07`: the on-behalf-of dimension is `AuthorityContext`
+  and no upstream concept is redefined.
+
+Concept placement across the boundary — one owning canon and one import
+direction per shared concept — is recorded in
+[concept-placement.md](infospace/interfaces/concept-placement.md), with the
+supporting survey of InfoTechCanon's existing authority vocabulary in
+[infotechcanon-authority-survey.md](infospace/mappings/infotechcanon-authority-survey.md).
 
 ## Exclusions and evolution
 
diff --git a/workplans/SECURITY-WP-0001-bootstrap-and-vocabulary.md b/workplans/SECURITY-WP-0001-bootstrap-and-vocabulary.md
index 8c47799..184076f 100644
--- a/workplans/SECURITY-WP-0001-bootstrap-and-vocabulary.md
+++ b/workplans/SECURITY-WP-0001-bootstrap-and-vocabulary.md
@@ -4,7 +4,7 @@ type: workplan
 title: "Bootstrap security-canon and establish the Mode of Authority vocabulary"
 domain: infotech
 repo: security-canon
-status: active
+status: finished
 owner: claude
 topic_slug: security-canon
 created: "2026-09-20"
@@ -332,3 +332,41 @@ The two amendments are applied to the placement table and to `imports.json`
 through the procedure SECURITY-DEC-2026-003 requires, taking the declared import
 list from ten concepts to twelve. No InfoTechCanon file is changed by this
 survey; R-3 is InfoTechCanon-internal work.
+
+## Closure — 2026-09-20
+
+All tasks are resolved: T01, T02, T03, T04, T06 and T07 done, T05 cancelled.
+
+The workplan set out to establish SecurityCanon as a governed repository and to
+produce the reviewed disposition that a migration would follow. It delivered the
+repository, the Mode of Authority vocabulary at v0.2.0, the federation interface
+card, three decisions, the concept-placement record and the reference-impact
+survey — and it concluded that the migration it was preparing should not happen.
+Nothing moves. The boundary holds by declared imports in both directions, twelve
+InfoTechCanon concepts pinned in `imports.json` and nine concepts owned here.
+
+That is a change of premise worth stating plainly. The repository owner asked on
+2026-09-20 to refine InfoTechCanon by moving its IT-security material into a
+dedicated canon. The review found that the material is load-bearing where it
+sits — CARING imports eleven upstream models, the security model is a posture
+model of the shared spine, the DevSecOps model belongs beside the
+repository-layout standard — and that SecurityCanon's real contribution is an
+architecture-layer vocabulary that InfoTechCanon does not have. SecurityCanon is
+therefore an extension canon, not a destination for extracted material. T05, the
+migration handoff, was cancelled rather than deferred.
+
+Two corrections were made against this workplan's own earlier output rather than
+being left to stand: `itc-org:Authority` and `Environment` were missing from the
+placement table, and `Scope` was attributed to the wrong owner. Both were fixed
+through the amendment procedure SECURITY-DEC-2026-003 requires.
+
+Residuals handed to InfoTechCanon: R-1 is resolved there
+(ADHOC-2026-09-20-T01); R-2, the CARING section 32 generalisation, and R-3, the
+two senses of Authority inside InfoTechCanon, remain open and are that
+repository's to decide. A follow-up worth its own workplan: the `owned_concepts`
+conflict check cannot see a concept that is live and referenced by qualified id
+but undeclared, which is how F-1 escaped the boundary review.
+
+Limits. Everything recorded here is agent review, not human sign-off, and
+records no consumer adoption or conformance claim. The G7 validator in
+`prj-canon-federation` still does not pin the security-canon card.