create-filegrc 0.8.0 → 0.9.1

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "create-filegrc",
-  "version": "0.8.0",
+  "version": "0.9.1",
   "description": "Create a filegrc workspace for a SOC 2 program",
   "license": "MIT",
   "repository": {

package/src/defaults.js

@@ -374,9 +374,9 @@ const controls = [
     id: "control-backup-restoration",
     code: "BCP-01",
     title: "Backup and restoration",
-    statement: "Each important System has backup scope, frequency, retention, monitoring, and restore validation that meet its approved recovery objectives, or a documented alternate recovery approach when backups are not the chosen safeguard.",
+    statement: "Each important System has risk-based backup or alternate recovery scope, frequency, retention, monitoring, and restore validation suited to its recovery needs and any approved recovery targets.",
     requirements: ["CC7.5", "CC9.1"],
-    activity: "Record System recovery objectives and backup or alternate recovery procedures, monitor the chosen safeguards, and validate recovery on the approved schedule.",
+    activity: "Record backup or alternate recovery procedures, monitor the chosen safeguards, and validate recovery on the approved schedule.",
     controlType: "corrective",
     operationMode: "hybrid",
     operationPattern: "scheduled",
@@ -388,7 +388,7 @@ const controls = [
     title: "Continuity planning and exercise",
     statement: "The organization maintains recovery priorities and responsibilities, reviews emergency contacts annually, and tests its continuity and disaster recovery plan at least annually.",
     requirements: ["CC7.5", "CC9.1"],
-    activity: "Maintain the plan, contacts, recovery objectives, exercises, results, and follow-up work.",
+    activity: "Maintain the plan, contacts, recovery priorities, exercises, results, and follow-up work.",
     controlType: "corrective",
     operationMode: "manual",
     operationPattern: "mixed",

package/src/index.js

@@ -523,13 +523,13 @@ async function runCombinedSetup(target, input) {
 async function writeMinimalLockfile(target, name, versionRange) {
   const lock = {
     name,
-    version: "0.8.0",
+    version: "0.9.1",
     lockfileVersion: 3,
     requires: true,
     packages: {
       "": {
         name,
-        version: "0.8.0",
+        version: "0.9.1",
         dependencies: { filegrc: versionRange }
       }
     }

package/template/AGENTS.md

@@ -100,12 +100,12 @@ Do not rewrite or remove committed records that explain prior audit periods. Clo
 If the installed CLI reports that this workspace uses an unsupported model, start with:
 
 ```sh
-npx filegrc migrate --to-model 5 --preview --json
+npx filegrc migrate --to-model 6 --preview --json
 ```
 
-Older workspaces migrate one version at a time. Review every preview’s automatic, review-required, and unsupported classifications before applying it with the same options and `--yes`. The v5 migration adds explicit program or engagement scope, preserves known Document approval facts, and creates no activation event, actor, revision, or date. It keeps historical Documents from issued or completed Audits active with a visible `legacy-v4` activation basis.
+Older workspaces migrate one version at a time. Review every preview’s automatic, review-required, and unsupported classifications before applying it with the same options and `--yes`. The v6 migration separates Training approval from activation, preserves existing active Training with a visible `legacy-v5` activation basis, and removes Training schedule fields because Obligations now own assignment timing.
 
-The [model v5 upgrade guide](https://github.com/Alignbase/filegrc/blob/main/docs/upgrading-to-model-v5.md) explains the separate Document approval and activation review.
+The [model v6 upgrade guide](https://github.com/Alignbase/filegrc/blob/main/docs/upgrading-to-model-v6.md) explains the Training lifecycle and Obligation review.
 
 Run these commands when working with records:
 
@@ -206,14 +206,14 @@ npx filegrc program-readiness --require-ready --summary --json
 The Evidence Ready gate requires:
 
 1. A management goal, selected systems, criteria, and controls.
-2. Policy content and required program plans and schedules independently approved in Step 2, with approval dates and exact approved content revisions.
-3. Implemented Controls with an owner, actual procedure, scope, operation pattern, mappings, implementation date, and every required linked Work Queue schedule enabled. Required governed Documents must then be activated in Step 3 with separate activation dates and exact activation revisions.
+2. Policies, required program Documents, and Training independently approved in Step 2, with approval dates and exact approved content revisions.
+3. Implemented Controls with an owner, actual procedure, scope, operation pattern, mappings, implementation date, and every required linked Obligation enabled. Required program Documents and Training must then be activated in Step 3 with separate activation dates and exact activation revisions.
 4. Every selected Control mapped to active authoritative Components with the required evidence source roles, current access owners, and repeatable extraction instructions in Record Markdown.
-5. Required governed plans and schedules active and effective, with no unresolved activation blockers. Audit-specific Documents remain in Step 5 and do not satisfy this program gate.
+5. Required governed content active and effective, with no unresolved activation blockers. Audit Documents remain in Step 5 and do not satisfy this program gate.
 
-A Policy says what the company commits to do by the date it takes effect. Approval means the company accepts those commitments. It does not prove the work is done. Controls and operating records describe how the company meets them and provide the proof. A Control may be implemented against an approved inactive Policy or required program Document. Enabled Obligations remain dormant until the Policy and required program Documents are active and effective.
+A Policy says what the company commits to do by the date it takes effect. Approval means the company accepts those commitments. It does not prove the work is done. Controls and operating records describe how the company meets them and provide the proof. A Control may be implemented against an approved inactive Policy, required program Document, or Training record. Enabled Obligations remain dormant until all of their governing content is active and effective.
 
-Review `documentActivations` and `policyActivations` in Program Readiness before cutover. Complete and approve intended Document values in Step 2. After the linked Controls are implemented, use `npx filegrc activate-documents --scaffold` to record the active Person who performs the cutover plus the actual Step 3 activation and effective dates against the unchanged approved revision. Then use the Controls-page review or `npx filegrc activate-policies --scaffold` to choose which approved Policies take effect. Evidence Readiness remains incomplete until every required program Document and Policy is active and operating. Operate and collect Evidence in Step 4. Keep engagement terms, management assertions, representation letters, and other audit-specific Documents in Step 5. Approve and activate each audit-specific Document there as separate writes after its engagement facts are complete.
+Review `documentActivations`, `trainingActivations`, and `policyActivations` in Program Readiness before cutover. Approve Policies, program Documents, and Training in Step 2. Define schedules as Obligations and implement the linked Controls in Step 3, then use `npx filegrc activate-content --scaffold` to record the active Person and actual activation and effective dates against each unchanged approved revision. Use the Controls-page review or `npx filegrc activate-policies --scaffold` to choose which approved Policies take effect. Evidence Readiness remains incomplete until every required program artifact is active and operating. Operate and collect Evidence in Step 4. Keep engagement terms, management assertions, representation letters, and other Audit Documents in Step 5. Approve and activate each Audit Document there as separate writes after its engagement facts are complete.
 
 Onboarding does not create Evidence Artifacts. Complete authoritative source Components as part of Control implementation. For every incomplete family in Program Readiness, update the Control with its authoritative `evidenceSourceComponentIds`, then give each source Component the required evidence role, current access owners, and repeatable retrieval instructions in Record Markdown. Use `npx filegrc evidence-map --json` when you want only those source checks. During Step 4, create an Evidence Artifact only when a real artifact exists. Select its `sourceComponentId`, attach or reference the result, link the Controls and operating record it supports, record its collector and Classification, then have another person verify it before audit use.
 

package/template/README.md

@@ -19,7 +19,7 @@ npm run serve
 
 Requires Node.js 20 or newer and Git.
 
-Existing model v4 workspaces must run `npx filegrc migrate --to-model 5 --preview --json` after installing a model v5 package. The migration assigns each Document to the program or engagement workflow, preserves each known approval, moves active Documents that still need a distinct activation back to approved, and keeps the old effective date as proposed. It preserves management Documents from issued and completed Audits with a visible legacy basis instead of rewriting history. Review the result, implement or confirm the linked requirements, then activate the exact approved revisions in Step 3. Older workspaces migrate one model version at a time. See the [model v5 upgrade guide](https://github.com/Alignbase/filegrc/blob/main/docs/upgrading-to-model-v5.md).
+Existing model v5 workspaces must run `npx filegrc migrate --to-model 6 --preview --json` after installing a model v6 package. The migration gives Training separate approval and activation facts, preserves active model v5 Training with a visible legacy basis, and removes Training schedule fields because Obligations now own assignment timing. Review the result and confirm or create each Training Obligation in Step 3. Older workspaces migrate one model version at a time. See the [model v6 upgrade guide](https://github.com/Alignbase/filegrc/blob/main/docs/upgrading-to-model-v6.md).
 
 ## How it works
 
@@ -40,16 +40,16 @@ Detached and feature-branch checkouts are read-only in the browser by default. D
 ![filegrc SOC 2 program overview](docs/filegrc-home.png)
 
 1. **Define scope.** Set program ownership, choose the criteria, and define the service, Systems, and providers in scope.
-2. **Approve policies and plans.** Tailor each Policy and complete the intended values in required governed plans and schedules. Have someone other than the owner approve each exact revision. Approval does not mean the linked Controls are implemented.
-3. **Implement controls.** Implement the approved requirements, define how each Control works, connect its Evidence sources, and enable its schedules. Activate each unchanged approved plan or schedule with a separate activation date and revision, then activate the selected Policy cutover set.
+2. **Approve policies.** Review Policies, program Documents, and Training in one table. Have someone other than the owner approve each exact revision. Approval does not mean the linked Controls are implemented.
+3. **Implement controls.** Implement the approved requirements, define how each Control works, connect its Evidence sources, and configure Obligations. Activate each unchanged approved Document or Training record with a separate activation date and revision, then activate the selected Policy cutover set.
 4. **Operate the program.** Run scheduled and event-driven work, maintain risk, and retain dated evidence.
 5. **Audit.** Set up the CPA engagement, support fieldwork, and prepare the evidence packet.
 
 A Policy says what the company commits to do by the date it takes effect. Approval means the company accepts those commitments. It does not prove the work is done. Controls and operating records describe how the company meets them and provide the proof.
 
-FileGRC does not infer technical implementation from Policy prose. Configuration facts belong in Controls, Components, Systems, governed schedules, and Evidence. A Control may be implemented while its governing Policy or required program Document is approved but inactive. Enabled Obligations remain dormant until the Policy and required program Documents are active and effective.
+FileGRC does not infer technical implementation from Policy prose. Configuration facts belong in Controls, Components, Systems, Obligations, and Evidence. A Control may be implemented while its governing Policy, required program Document, or Training is approved but inactive. Enabled Obligations remain dormant until all of their governing content is active and effective.
 
-Control implementation includes evidence-source, schedule, and governed-Document readiness. Use `npx filegrc program-readiness --json` to review incomplete Control or Component records plus `documentActivations` and `policyActivations`. Activate ready plans and schedules with `npx filegrc activate-documents --scaffold`; name the active Person who performs activation, and keep approval and activation as separate dates and content-revision bindings. Then use the Controls-page review or `npx filegrc activate-policies --scaffold` to choose which approved Policies take effect. Evidence Readiness requires active Policies and required program Documents, implemented Controls, configured evidence sources, and enabled schedules before the candidate period can begin. Create Evidence during Step 4 only after operation produces a real record or artifact. Create engagement terms, management assertions, representation letters, and other audit-specific Documents in Step 5, link each to one Audit, approve it, then activate it with `npx filegrc activate-documents --audit AUDIT_ID --scaffold`. Evidence packets include the separate approval and activation facts and exact content revisions in `document-lifecycle-index.csv`.
+Control implementation includes evidence-source, Obligation, and governed-content readiness. Use `npx filegrc program-readiness --json` to review incomplete Control or Component records plus `documentActivations`, `trainingActivations`, and `policyActivations`. Activate ready program Documents and Training with `npx filegrc activate-content --scaffold`; name the active Person who performs activation, and keep approval and activation as separate dates and content-revision bindings. Then use the Controls-page review or `npx filegrc activate-policies --scaffold` to choose which approved Policies take effect. Evidence Readiness requires active Policies, required program Documents, Training, implemented Controls, configured evidence sources, and enabled Obligations before the candidate period can begin. Create Evidence during Step 4 only after operation produces a real record or artifact. Create engagement terms, management assertions, representation letters, and other Audit Documents in Step 5, link each to one Audit, approve it, then activate it with `npx filegrc activate-documents --audit AUDIT_ID --scaffold`.
 
 The Program Overview shows what is done, what is blocked, and what to do next.
 

package/template/data/AGENTS.md

@@ -116,7 +116,7 @@ Status is an assertion. Before moving a record to a completed, approved, impleme
 
 Do not mark a control implemented because a policy says it should exist. Do not mark evidence verified because it was merely collected. Do not mark a task done without the completion record type requested by its obligation.
 
-Policy and governed-Document approval in Step 2 accepts the reviewed requirements, intended values, and exact content revisions. It does not prove implementation or start governed work. A required program plan or schedule has `workflowScope: program` and stays `approved` until its linked Controls are implemented. In Step 3, run `activate-documents --scaffold` and record the active Person who performs the cutover, actual activation date, and effective date; FileGRC binds the activation to the unchanged content as a separate revision event. Then run `activate-policies --scaffold`, review the approved Policies together, select the cutover set, and record the real effective date. Operate the program and collect Evidence in Step 4. Create audit-specific Documents with `workflowScope: engagement` only in the Step 5 workflow. After each audit Document is complete, record approval first, then activate the unchanged approved revision in a separate update with its actor, actual activation date, and effective date.
+Policy, program Document, and Training approval in Step 2 accepts the reviewed requirements, intended values, and exact content revisions. It does not prove implementation or start governed work. A required program Document has `workflowScope: program`, and Training stays `approved`, until linked Controls and Obligations are ready. In Step 3, run `activate-content --scaffold` and record the active Person who performs the cutover, actual activation date, and effective date; FileGRC binds activation to each unchanged approved revision. Then run `activate-policies --scaffold`, review the approved Policies together, select the cutover set, and record the real effective date. Operate the program and collect Evidence in Step 4. Create Audit Documents with `workflowScope: engagement` only in the Step 5 workflow. After each Audit Document is complete, record approval first, then activate the unchanged approved revision in a separate update with its actor, actual activation date, and effective date.
 
 ## Delete and replace
 
@@ -206,7 +206,7 @@ npx filegrc audit-readiness AUDIT_ID --json
 npx filegrc evidence-packet --audit AUDIT_ID --preview --json
 ```
 
-Run Program Readiness before creating the normal audit engagement. Step 2 checks independent Policy and required governed-Document approval without requiring activation. Step 3 separately checks active Documents, their activation dates and bound revisions, active Policies, implemented Controls, enabled schedules, and evidence mapping without an audit ID. Fix readiness errors in Policy, Document, Control, Component, System, schedule, and Evidence records. Do not edit packet output under `.filegrc/`. A delivery-ready filegrc packet means the management checks passed; the engagement team still judges evidence and performs the examination.
+Run Program Readiness before creating the normal audit engagement. Step 2 checks independent approval of Policies, required program Documents, and Training without requiring activation. Step 3 separately checks active Documents and Training, their activation dates and bound revisions, active Policies, implemented Controls, enabled Obligations, and evidence mapping without an audit ID. Fix readiness errors in Policy, Document, Training, Control, Component, System, Obligation, and Evidence records. Do not edit packet output under `.filegrc/`. A delivery-ready filegrc packet means the management checks passed; the engagement team still judges evidence and performs the examination.
 
 For a real engagement, select the Program and its bounded Systems, a framework containing the complete CC1.1 through CC9.2 Security Common Criteria set, all nine SOC 2 Description Criteria, any optional Trust Services Categories in scope, and Controls that cover every applicable selected Trust Services criterion. Treat every Security Common Criterion as applicable. For an included optional category, keep a criterion in the framework when management judges it not relevant and record the limited circumstances in the System Description's DC8 disclosure. Do not omit any of the nine Description Criteria. Use `coverage.kind: "as-of"` with `on` for Type 1 or `coverage.kind: "range"` with `startsOn` and `endsOn` for Type 2. Record the Git commit for management's complete scope review in `scopeRevision`. Record `subserviceConclusion` and its rationale. When subservice organizations are identified, each `subserviceTreatments` item must connect one Vendor to its supplied Components within a selected System and choose the carve-out or inclusive method. Inclusive treatments also need the selected Controls that operate on those Components.
 

package/template/data/documents/document-data-retention-schedule.md

@@ -11,7 +11,7 @@ Retention periods may come from law, contract, tax, audit, security, or a docume
 | Record class | System or location | Owner | Trigger | Retention | End-of-period action | Authority or reason |
 | --- | --- | --- | --- | --- | --- | --- |
 | Security logs for important Systems | [Complete before approval: Systems or Components] | [Complete before approval: owner] | Log event | [Confirm or replace proposed default before approval: 12 months, adjusted for investigation, contract, legal, audit, and risk needs] | [Complete before approval: disposal action] | [Complete before approval: authority or reason] |
-| Production backups or alternate recovery copies | [Complete before approval: Systems or Components] | [Complete before approval: owner] | Backup or recovery-copy creation | [Confirm or replace proposed default before approval: 30 days, adjusted to approved System recovery objectives] | [Complete before approval: expiration or disposal action] | [Complete before approval: continuity objective or risk decision] |
+| Production backups or alternate recovery copies | [Complete before approval: Systems or Components] | [Complete before approval: owner] | Backup or recovery-copy creation | [Confirm or replace proposed default before approval: 30 days, adjusted to approved System recovery needs] | [Complete before approval: expiration or disposal action] | [Complete before approval: recovery need, commitment, or risk decision] |
 | SOC 2 Policies, Control records, and audit Evidence | Git repository and approved Evidence locations | Policy owner | End of the relevant audit period | [Complete before approval based on audit, contract, and legal needs] | Archive or securely delete | Audit and business requirements |
 | Customer and service records | [Complete before approval: Systems or Components] | [Complete before approval: owner] | [Complete before approval: trigger] | [Complete before approval: retention] | Delete or anonymize | Contract, law, and business need |
 | Incident and investigation records | Approved incident and Evidence Systems | Incident owner | Incident closure | [Complete before approval: retention] | Archive or securely delete | Legal, insurance, contract, and security needs |

package/template/data/documents/document-security-incident-recovery-plan.md

@@ -49,7 +49,7 @@ The team does not destroy Evidence, promise external notification, or make publi
 
 ## Recovery priorities and procedures
 
-[Complete before activation: Document every important System's approved recovery time objective, recovery point objective, maximum tolerable downtime, dependencies, owner, and critical customer commitments.]
+[Complete before activation: Identify every important System's recovery priority, dependencies, owner, backup or alternate recovery approach, and critical customer commitments. Record numeric recovery targets only when an approved commitment, included Availability criterion, or risk decision requires them.]
 
 Supporting recovery documentation for each important System must identify:
 
@@ -59,6 +59,7 @@ Supporting recovery documentation for each important System must identify:
 - People who can access the procedure and required Systems
 - Restore-validation method and approved schedule
 - Dependencies, fallback paths, and validation steps
+- Any recovery targets required by an approved commitment, included Availability criterion, or risk decision
 
 [Confirm or replace before activation: The proposed starting point for important production data is a daily backup, 30-day retention period, and annual restore validation. Document the approved choice for every important System in its recovery procedures and the Data Retention Schedule.]
 

package/template/data/policies/AGENTS.md

@@ -2,7 +2,7 @@
 
 A Policy says what the company commits to do by the date it takes effect. Approval means the company accepts those commitments. It does not prove the work is done. Controls and operating records describe how the company meets them and provide the proof.
 
-FileGRC does not infer technical implementation from Policy prose. Put configuration facts in Controls, Components, Systems, governed schedules, and Evidence.
+FileGRC does not infer technical implementation from Policy prose. Put configuration facts in Controls, Components, Systems, Obligations, and Evidence.
 
 Keep durable mandatory outcomes in Policy prose. Put adjustable values such as retention periods, scan cadence, recovery frequency, and review windows in the linked Control, System, Document schedule, or Obligation. Starter values are proposals: management must confirm or replace each value before it counts as configured.
 
@@ -14,11 +14,11 @@ The Security starter contains one consolidated Information Security Policy. Its
 
 Add another Policy only when management expands the program scope or has a distinct approval audience, owner, or legal requirement.
 
-During Step 3, implement Controls while the governing Policy is approved but inactive. Configure and enable its schedules, which remain dormant. Use the Controls-page cutover or `activate-policies --scaffold` to review the approved Policy. Before selecting it for activation:
+During Step 3, implement Controls while the governing Policy is approved but inactive. Configure and enable its Obligations, which remain dormant. Use the Controls-page cutover or `activate-policies --scaffold` to review the approved Policy. Before selecting it for activation:
 
 1. Review the per-Policy activation assessment.
 2. Review linked Controls that are planned or partial, missing Components or evidence sources, missing schedules, and unresolved Exceptions.
-3. Confirm required governed plans and schedules have independent Step 2 approval, implement their linked requirements, and activate their exact approved revisions separately in Step 3.
+3. Confirm required program Documents and Training have independent Step 2 approval, implement their linked requirements and Obligations, and activate their exact approved revisions separately in Step 3.
 4. Set the real effective date and change the approved Policy to `active` at implementation cutover.
 5. If management activates with a known gap, document the decision, follow-up, and any time-bound Exception. Activation does not mark a Control implemented, and Evidence Readiness still requires active and operating Policies.
 

package/template/data/policies/policy-information-security.md

@@ -242,13 +242,13 @@ Reported events receive an owner, assessment, and documented resolution or escal
 
 ## Business Continuity and Disaster Recovery Policy
 
-Each important System records approved recovery priorities and objectives, dependencies, responsible people, alternate communication and access needs, and a backup or alternate recovery approach. Management selects continuity strategies according to service commitments, business impact, data risk, dependencies, and technical capability.
+Each important System records recovery priorities, dependencies, responsible people, alternate communication and access needs, and a backup or alternate recovery approach suited to its commitments, business impact, data risk, dependencies, and technical capability. Numeric recovery targets are required only when an approved customer commitment, included Availability criterion, or management risk decision calls for them.
 
 The Security Incident and Recovery Plan records activation, communication, response, recovery, and return-to-normal responsibilities. Management tests continuity and disaster recovery on the approved schedule, records results and findings, and tracks follow-up work.
 
 ## Backup and Restoration Policy
 
-Important Systems use backups or an approved alternate recovery approach that meets their recovery objectives. Management documents backup or alternate-recovery scope, frequency, retention, encryption and access needs, monitoring, failure response, procedures, and test schedules.
+Important Systems use backups or an approved alternate recovery approach suited to their recovery needs and any approved recovery targets. Management documents backup or alternate-recovery scope, frequency, retention, encryption and access needs, monitoring, failure response, procedures, and test schedules.
 
 Backup or recovery access is limited to authorized people and protected from the failures it is intended to address. Restoration or alternate recovery is validated on the approved schedule and after material change when prior results no longer represent the System. Policy adoption does not assert that every System uses daily backups or a fixed retention period.
 

package/template/data/training/training-security-awareness.json

@@ -10,8 +10,6 @@
     "employees",
     "contractors"
   ],
-  "assignmentTrigger": "onboarding",
-  "completionWindowDays": 30,
   "policyIds": [
     "policy-information-security"
   ],

package/template/data/workspace.json

@@ -1,5 +1,5 @@
 {
-  "dataModelVersion": "5",
+  "dataModelVersion": "6",
   "id": "workspace",
   "type": "workspace",
   "title": "{{program_title}}",

package/template/package.json

@@ -1,6 +1,6 @@
 {
   "name": "{{project_name}}",
-  "version": "0.8.0",
+  "version": "0.9.1",
   "private": true,
   "description": "filegrc workspace for a SOC 2 program",
   "type": "module",