create-filegrc 0.13.3 → 0.13.5

package/package.json

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

package/src/index.js

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

package/template/AGENTS.md

@@ -62,7 +62,7 @@ Read `data/AGENTS.md` before changing records. More specific instructions inside
 
 The JSON and Markdown under `data/`, the installed model, policy content, and Git history are the inputs to FileGRC’s shared workflow calculation. Source files hold facts, decisions, relationships, dates, status, and evidence references. They do not each need a copy of the generic audit-readiness instructions or calculated TODO list.
 
-Start with `npx filegrc program-path --next --json` for the current step and next action. Use `npx filegrc workflow --json` when you need the complete derived checklist, named readiness assessments, blockers, and Work Items. `guide`, `list --workflow`, `get --workflow`, mutation previews, the HTTP API, and the browser consume the same calculation. Resolve a derived finding by changing its source facts, recording a reviewed applicability decision, accepting an allowed Exception, or completing authoritative assigned work. Never add a separate TODO file or UI-only completion flag for calculated work.
+Start with `npx filegrc program-path --next --json` for the current step and next action. Use `npx filegrc workflow --json` when you need the complete derived checklist, named readiness assessments, blockers, and Work Items. `guide`, `list --workflow`, `get --workflow`, mutation previews, the HTTP API, and the browser consume the same calculation. In `get --workflow` output, `findings` and `workItems` preserve the complete checklist relevant to that record. `related` additionally groups downstream work that the record supports but that belongs to another record or program step. Resolve a derived finding by changing its source facts, recording a reviewed applicability decision, accepting an allowed Exception, or completing authoritative assigned work. Never add a separate TODO file or UI-only completion flag for calculated work.
 
 FileGRC marks an item `blocked` only when named prerequisite records must be resolved first. A missing record, editable error, or management decision is `ready` when you can act on it now, even when it prevents a readiness assessment from passing.
 

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

@@ -2,7 +2,7 @@
 
 ## Use
 
-This schedule records how long {{company_name}} keeps important record classes and what happens when each period ends. The policy owner and data owners must complete the organization-specific rows before approval.
+This schedule records how long {{company_name}} keeps important record classes and what happens when each period ends.
 
 Retention periods may come from law, contract, tax, audit, security, or a documented business need. Use the longest applicable period, but do not keep data indefinitely without a reason.
 
@@ -10,7 +10,7 @@ Retention periods may come from law, contract, tax, audit, security, or a docume
 
 The structured Retention Schedule Items linked to this document are its schedule rows. Each approved item must name the covered Information Types and operational scope, owner, cutoff, period, disposition action, instructions, and authority. Planned items are review prompts and are not approved retention behavior.
 
-Management must cover important information used by Systems, Components, and Vendors, including security logs, backups or alternate recovery copies, governance records, audit evidence, customer and service records, and incident records when those classes exist. No starter period or disposition action is an approved organization value.
+Management must cover important information used by Systems, Components, and Vendors, including security logs, backups or alternate recovery copies, governance records, audit evidence, customer and service records, and incident records when those classes exist. A proposed period or disposition action is not an approved organization value.
 
 ## Holds and exceptions
 

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

@@ -8,13 +8,13 @@ This plan coordinates reporting, response, recovery, and continuity when a secur
 
 People send suspected security concerns through the current approved normal reporting channel, such as the security email address. If that channel is unavailable, compromised, or involved in the concern, they use the approved fallback channel. The Reporting Channel Set is the source of truth for the current destinations, responsible role, and effective period.
 
-[Complete before activation: Describe how workers can find the fallback reporting channel when the normal email, identity, or collaboration System is unavailable, compromised, or involved in the concern. Do not copy the destination here or include plaintext credentials, private keys, tokens, or recovery codes.]
+[Describe how workers find the fallback reporting channel when the normal email, identity, or collaboration System is unavailable, compromised, or involved in the concern. Do not copy the destination here or include plaintext credentials, private keys, tokens, or recovery codes.]
 
 Reports may describe suspected unauthorized access, malware, data loss, credential exposure, security-Control failure, service disruption, fraud affecting the service, or another policy violation. The recipient records the report, protects confidentiality, preserves relevant information, and assigns an initial owner.
 
 ## Roles and authority
 
-The Policy Owner maintains this plan and ensures that the organization assigns these duties before activation:
+The Policy Owner maintains this plan and ensures that the organization assigns these duties:
 
 - Incident lead with authority to declare, coordinate, escalate, and close an incident
 - Technical recovery lead for containment, restoration, validation, and rollback
@@ -24,7 +24,7 @@ The Policy Owner maintains this plan and ensures that the organization assigns t
 
 If an incident raises a legal, privacy, or insurance question, the incident lead obtains suitable advice at that time. A pre-arranged counsel relationship or standing legal retainer is required only when management determines that the organization's obligations and risk warrant one.
 
-[Complete before activation: Record the emergency contact arrangement, its owner, alternate communication channel, protected storage location, and review schedule.]
+[Describe the emergency contact arrangement, its owner, alternate communication channel, protected storage location, and review schedule.]
 
 ## Assessment and declaration
 
@@ -49,7 +49,7 @@ The team does not destroy Evidence, promise external notification, or make publi
 
 ## Recovery priorities and procedures
 
-[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.]
+[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:
 
@@ -61,13 +61,13 @@ Supporting recovery documentation for each important System must identify:
 - 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.]
+[Document the management-approved recovery approach for every important System in its recovery procedures and the Data Retention Schedule. A daily backup, 30-day retention period, and annual restore validation are examples, not approved organization values.]
 
 If no approved objective or procedure exists during an event, the incident lead records an interim decision based on customer impact, data risk, and dependencies, then assigns the missing permanent decision as follow-up work.
 
 ## Alternate plan access
 
-[Complete before activation: Record the protected alternate location and access method responders will use when the primary identity, source-control, or collaboration Systems are unavailable. Confirm that authorized responders can retrieve the plan without exposing plaintext secrets or decryption keys.]
+[Describe the protected alternate location and access method responders use when the primary identity, source-control, or collaboration Systems are unavailable. Confirm that authorized responders can retrieve the plan without exposing plaintext secrets or decryption keys.]
 
 ## Closure and follow-up
 

package/template/data/documents/document-soc2-management-assertion.md

@@ -1,7 +1,6 @@
 # {{company_name}} Management Assertion
 
-> Draft preparation document. Retain the section that matches the engagement, remove the other draft section, and reconcile the final wording with the service auditor before approval.
-
+<!-- type-1:start -->
 ## Type 1 Assertion Draft
 
 Management is responsible for the attached description of the in-scope system as of [as-of date] and for designing, implementing, and documenting the controls within that system.
@@ -10,7 +9,9 @@ Based on the criteria selected for the engagement, management asserts that:
 
 1. The attached description presents the system as designed and implemented as of [as-of date], in accordance with the applicable SOC 2 Description Criteria.
 2. The controls stated in the description were suitably designed to provide reasonable assurance that the applicable service commitments, system requirements, and Trust Services Criteria would be met, assuming the complementary controls identified in the description operated effectively.
+<!-- type-1:end -->
 
+<!-- type-2:start -->
 ## Type 2 Assertion Draft
 
 Management is responsible for the attached description of the in-scope system for [start date] through [end date] and for designing, implementing, operating, and documenting the controls within that system.
@@ -20,5 +21,6 @@ Based on the criteria selected for the engagement, management asserts that:
 1. The attached description presents the system as designed and implemented during [start date] through [end date], in accordance with the applicable SOC 2 Description Criteria.
 2. The controls stated in the description were suitably designed to provide reasonable assurance that the applicable service commitments, system requirements, and Trust Services Criteria would be met, assuming the complementary controls identified in the description operated effectively.
 3. The controls operated effectively throughout [start date] through [end date].
+<!-- type-2:end -->
 
 [Identify the responsible management signer, title, signature or approval method, and date.]

package/template/data/documents/document-soc2-management-representation.md

@@ -1,8 +1,8 @@
 # {{company_name}} Management Representation Letter
 
-> The service auditor normally supplies the required representation-letter wording near the end of fieldwork. Replace this preparation note with the agreed final letter, obtain the required management signature, and retain the signed fixed-format copy as linked evidence.
+> [Insert the final management representation agreed with the service auditor.]
 
-Before signing, reconcile the auditor's letter to:
+The signer confirms that the letter agrees with:
 
 - The final system description and management assertion
 - The reporting date or period, [engagement date or period], and selected criteria

package/template/data/documents/document-soc2-system-description.md

@@ -1,6 +1,6 @@
 # {{company_name}} SOC 2 System Description
 
-> Draft preparation document. Complete every bracketed item, reconcile it to management's authoritative records, and have the service auditor review the final presentation.
+> [Describe the service as it existed for the stated reporting date or period.]
 
 ## Reporting Period and Scope
 
@@ -16,7 +16,7 @@
 
 ## DC2: Service Commitments and System Requirements
 
-[Summarize customer commitments, contractual security promises, internal objectives, and the system requirements needed to meet them. Reconcile the summary to supporting commitment records.]
+[Summarize customer commitments, contractual security promises, internal objectives, and the system requirements needed to meet them.]
 
 ## DC3: System Components
 

package/template/data/reporting-route-sets/reporting-route-set-security-reporting.md

@@ -1,6 +1,6 @@
 # Security reporting channels
 
-This record tells FileGRC where people should send security concerns. A channel can be an email address, phone number, web form, named in-person contact, or another clear destination.
+This draft proposes normal and fallback channels for reporting security concerns. A channel can be an email address, phone number, web form, named in-person contact, or another clear destination.
 
 - The normal channel is the method people should use first.
 - The fallback channel must still work when the normal channel is unavailable, compromised, or involved in the concern.

package/template/package.json

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