create-filegrc 0.7.0 → 0.8.0

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

@@ -16,11 +16,11 @@ Retention periods may come from law, contract, tax, audit, security, or a docume
 | 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 |
 
-Add rows for each important data class in the System and Vendor inventories. A row is incomplete until it names the source System or Component, owner, trigger, period, disposal action, and authority. FileGRC detects the bracketed prompts as approval blockers. Remove each prompt only after replacing it with a reviewed fact.
+Add rows for each important data class in the System and Vendor inventories. A row is incomplete until it names the source System or Component, owner, trigger, period, disposal action, and authority. Remove each bracketed prompt only after replacing it with a reviewed fact.
 
 ## Holds and exceptions
 
-An approved legal hold, investigation, or preservation duty suspends normal deletion for the affected records. Record the authority, scope, owner, start date, and release decision outside this public template.
+An approved legal hold, investigation, or preservation duty suspends normal deletion for the affected records. Record the authority, scope, owner, start date, and release decision in controlled legal-hold records.
 
 Any retention exception needs a reason, owner, approval, compensating safeguards, and expiration or next review date.
 

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

@@ -4,6 +4,7 @@
   "title": "Security Incident and Recovery Plan",
   "status": "draft",
   "documentKind": "plan",
+  "workflowScope": "program",
   "ownerIds": [
     "appointment-policy-owner"
   ],

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

@@ -2,13 +2,13 @@
 
 ## Purpose
 
-This plan coordinates reporting, response, recovery, and continuity when a security event or disruption affects {{company_name}} or an in-scope service. Controls, Components, Systems, Obligations, and Evidence hold the actual technical configuration and proof of operation.
+This plan coordinates reporting, response, recovery, and continuity when a security event or disruption affects {{company_name}} or an in-scope service. Supporting procedures, system records, and retained evidence document the actual technical configuration and operation.
 
 ## Reporting routes
 
 The primary reporting route is {{security_contact_email}}.
 
-[Complete before activation: Name a usable alternate reporting route, its owner, protected location, and how workers can find it when the primary email, identity, or collaboration System is unavailable, compromised, or involved in the concern. Do not put secrets in this plan.]
+[Complete before activation: Name a usable alternate reporting route, its owner, protected location, and how workers can find it when the primary email, identity, or collaboration System is unavailable, compromised, or involved in the concern. Do not put plaintext credentials, private keys, tokens, or recovery codes in this plan.]
 
 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.
 
@@ -22,7 +22,7 @@ The Policy Owner maintains this plan and ensures that the organization assigns t
 - Executive decision-maker for major business, customer, insurance, or legal decisions
 - Communication owner for workforce, customer, Vendor, and public messages
 
-If an incident raises a legal, privacy, or insurance question, the incident lead gets suitable advice at that time. FileGRC does not require pre-arranged counsel, in-house counsel, or a standing legal retainer.
+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.]
 
@@ -49,24 +49,24 @@ The team does not destroy Evidence, promise external notification, or make publi
 
 ## Recovery priorities and procedures
 
-[Complete before activation: Link every important System and record its approved recovery time objective, recovery point objective, maximum tolerable downtime, dependencies, owner, and critical customer commitments in the System record.]
+[Complete before activation: Document every important System's approved recovery time objective, recovery point objective, maximum tolerable downtime, dependencies, owner, and critical customer commitments.]
 
-For each important System, the applicable Control, Component, System, and Obligation records must identify:
+Supporting recovery documentation for each important System must identify:
 
 - The backup or alternate recovery approach
 - Scope, frequency, retention, monitoring, and failure response
 - Recovery and restoration procedure
 - People who can access the procedure and required Systems
-- Restore-validation method and governed schedule
+- Restore-validation method and approved schedule
 - Dependencies, fallback paths, and validation steps
 
-[Confirm or replace before activation: The starter proposal for important production data is a daily backup, 30-day retention period, and annual restore validation. Record the approved choice for every important System in its Control, Component, System, Retention Schedule, and Obligation records.]
+[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.]
 
 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 secrets.]
+[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.]
 
 ## Closure and follow-up
 
@@ -74,6 +74,6 @@ The incident lead closes the incident only after affected Systems are stable, se
 
 ## Exercises and maintenance
 
-Management tests a representative security alert from generation through receipt, acknowledgement, escalation, and fallback on the approved governed schedule. It also exercises incident coordination, alternate plan access, emergency contacts, and recovery of selected important Systems on their approved schedules.
+Management tests a representative security alert from generation through receipt, acknowledgement, escalation, and fallback on the approved schedule. It also exercises incident coordination, alternate plan access, emergency contacts, and recovery of selected important Systems on their approved schedules.
 
 Each exercise records scope, participants, objectives, result, Evidence, Exceptions, findings, and follow-up. The owner reviews this plan after a material incident, failed exercise, important System change, or reporting-path change and on the approved Policy-review schedule.

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

@@ -4,11 +4,11 @@
   "title": "SOC 2 Management Assertion",
   "status": "draft",
   "documentKind": "soc2-management-assertion",
+  "workflowScope": "engagement",
   "template": true,
   "ownerIds": [
     "appointment-policy-owner"
   ],
   "version": "0.1",
-  "classificationId": "confidential",
-  "programRole": "required"
+  "classificationId": "confidential"
 }

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

@@ -1,24 +1,24 @@
 # {{company_name}} Management Assertion
 
-> Draft preparation document. Reconcile this draft to the wording agreed with the service auditor before approval.
+> 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 Assertion Draft
 
-<!-- type-1:start -->
 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.
 
 Based on the criteria selected for the engagement, management asserts that:
 
-1. The description presents the system that was designed and implemented as of [as-of date].
+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.
 
 Based on the criteria selected for the engagement, management asserts that:
 
-1. The description presents the system that was designed and implemented during [start date] through [end date].
+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.json

@@ -4,11 +4,11 @@
   "title": "SOC 2 Management Representation Letter",
   "status": "draft",
   "documentKind": "soc2-management-representation",
+  "workflowScope": "engagement",
   "template": true,
   "ownerIds": [
     "appointment-policy-owner"
   ],
   "version": "0.1",
-  "classificationId": "confidential",
-  "programRole": "required"
+  "classificationId": "confidential"
 }

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

@@ -17,4 +17,4 @@ Final letter received from auditor: [Date]
 
 Management signer and title: [Name and title]
 
-Signed letter evidence record: [Evidence ID]
+Signed letter reference: [Approved storage location or evidence reference]

package/template/data/documents/document-soc2-period-completeness.json

@@ -4,11 +4,11 @@
   "title": "SOC 2 Period Completeness Statement",
   "status": "draft",
   "documentKind": "soc2-period-completeness",
+  "workflowScope": "engagement",
   "template": true,
   "ownerIds": [
     "appointment-policy-owner"
   ],
   "version": "0.1",
-  "classificationId": "confidential",
-  "programRole": "conditional"
+  "classificationId": "confidential"
 }

package/template/data/documents/document-soc2-period-completeness.md

@@ -4,9 +4,9 @@
 
 Reporting period: [start date] through [end date]
 
-Management reconciled every audit-population record linked to this engagement to its authoritative source and included every item relevant to the in-scope system and controls. The generated `population-index.csv` is incorporated into this statement by reference and records each population ID, source system, query, timezone, count, validation, reviewer, conclusion, and fixed export.
+Management reconciled every population used for this engagement to its authoritative source and included every item relevant to the in-scope system and controls. The accompanying `population-index.csv` is incorporated into this statement by reference and records each population reference, source system, query, timezone, count, validation, reviewer, conclusion, and fixed export.
 
-| Population | filegrc population ID | Result or exception |
+| Population | Population reference | Result or exception |
 | --- | --- | --- |
 | Workforce starts, role changes, and departures | [Population ID] | [Result] |
 | Access grants, changes, reviews, and removals | [Population ID] | [Result] |
@@ -19,7 +19,7 @@ Management reconciled every audit-population record linked to this engagement to
 | Backup failures and restoration tests | [Population ID] | [Result] |
 | Security exceptions and control findings | [Population ID] | [Result] |
 
-For a population with zero items, retain the source-Component export or report that produced the zero count. Describe any source limitation, omitted item, or reconciliation difference below.
+For a population with zero items, retain the authoritative-source export or report that produced the zero count. Describe any source limitation, omitted item, or reconciliation difference below.
 
 ## Exceptions and Source Limitations
 
@@ -27,6 +27,6 @@ For a population with zero items, retain the source-Component export or report t
 
 ## Management Confirmation
 
-To the best of management's knowledge after the reconciliations above, filegrc and the linked evidence contain the complete populations and reportable events relevant to the engagement period.
+To the best of management's knowledge after the reconciliations above, management's records and linked evidence contain the complete populations and reportable events relevant to the engagement period.
 
 [Identify the responsible signer, title, signature or approval method, and date.]

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

@@ -4,11 +4,11 @@
   "title": "SOC 2 System Description",
   "status": "draft",
   "documentKind": "soc2-system-description",
+  "workflowScope": "engagement",
   "template": true,
   "ownerIds": [
     "appointment-policy-owner"
   ],
   "version": "0.1",
-  "classificationId": "internal",
-  "programRole": "required"
+  "classificationId": "internal"
 }

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 the filegrc records, and have the service auditor review the final presentation.
+> Draft preparation document. Complete every bracketed item, reconcile it to management's authoritative records, and have the service auditor review the final presentation.
 
 ## 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. Link the filegrc commitment records.]
+[Summarize customer commitments, contractual security promises, internal objectives, and the system requirements needed to meet them. Reconcile the summary to supporting commitment records.]
 
 ## DC3: System Components
 
@@ -46,7 +46,7 @@
 
 ## DC5: Applicable Criteria and Controls
 
-[Reference the selected criteria and control matrix generated by filegrc.]
+[Reference the selected criteria and management's control matrix.]
 
 ## DC6: Complementary User Entity Controls
 
@@ -58,7 +58,7 @@
 
 ## DC8: Criteria Not Relevant
 
-[Identify any criteria within an included category that are not relevant and explain why.]
+[State that CC1.1 through CC9.2 remain in scope for the mandatory Security category. For any optional Trust Services Category, identify a criterion that the service auditor agrees is not relevant in the limited circumstances allowed by the criteria, and explain why. Otherwise state that management identified no criteria as not relevant.]
 
 ## DC9: Significant Changes
 

package/template/data/evidence/AGENTS.md

@@ -29,4 +29,4 @@ For a signed acknowledgement, bind the attestation to the exact content Git revi
 
 For a `population-export`, also record the authoritative `sourceComponentId`, exact period, generation timestamp, timezone, query or report parameters, item count, completeness check, and accuracy check. A zero-item population still needs its source export and query.
 
-Do not commit secrets, session data, regulated data, or personal data that may need erasure. Use an approved external reference when Git is not an appropriate store.
+Do not commit plaintext credentials, private keys, tokens, recovery codes, session data, regulated data, or personal data that may need erasure. Source-controlled ciphertext is allowed only under the Information Security Policy's approved encryption, separate-key, access, and rotation conditions. Use an approved external reference when Git is not an appropriate store.

package/template/data/obligations/AGENTS.md

@@ -5,7 +5,7 @@ An obligation is a reusable policy schedule or event template. It is not the rec
 - Calendar obligations need a valid recurrence anchor, owners, expected completion types, and policy or control links.
 - Event obligations need a stable lowercase `eventType`, a prompt, owners, expected completion types, and an explicit deadline window.
 - Keep completed occurrences in `completionResourceIds`. Do not replace prior links when a new period starts.
-- Configure and enable Obligations during Step 3. An enabled Obligation remains dormant until every governing Policy is active and effective and, when it names Controls, at least one linked Control is implemented.
+- Configure and enable Obligations during Step 3. An enabled Obligation remains dormant until every governing Policy and required program Document is active and effective and, when it names Controls, at least one linked Control is implemented. FileGRC starts calendar work from the latest Policy or governed Document effective date, so pre-cutover periods do not become overdue work.
 - Calendar Obligations generated with `status: proposed` contain suggested starting cadences. Review the scope and risk, edit the cadence when needed, and change the Obligation to `active` only when management accepts that schedule. A proposed Obligation never counts as a configured schedule.
 - When an approved cadence changes, update the policy, control, and obligation together.
 - Pause or retire a template only when the underlying policy work no longer applies. Do not delete historical templates that explain prior periods.

package/template/data/policies/AGENTS.md

@@ -10,13 +10,15 @@ Use the `content` Markdown slot for the policy text. Keep ownership and approval
 
 Keep a Policy `draft` until its text, owner, scope, related Requirements and Controls, review Obligation, and acknowledgement requirement are ready for independent review. Move it to `approved` when management accepts the exact content revision. Approval does not require every linked Control to be implemented and does not make the Policy effective.
 
-The Security starter contains one Information Security Policy. Add another Policy only when management expands the program scope or has a distinct approval audience, owner, or legal requirement.
+The Security starter contains one consolidated Information Security Policy. Its section headings use common policy-family names so a customer, auditor, or questionnaire reviewer can locate topics such as access control, personnel security, vulnerability management, incident response, continuity, and Vendor risk. Cite the consolidated Policy and exact section when that accurately answers a request. Do not claim that each section is a separate document, that the heading proves implementation, or that FileGRC supplies a certification.
+
+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:
 
 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. Complete required governed plans and assign Training or Attestations.
+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.
 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.
 
@@ -25,3 +27,5 @@ The independent Policy approver is a management reviewer, not the CPA auditor. A
 If a proposed effective date has passed, choose a current or future activation date. Never backdate adoption.
 
 For a material revision, preserve Git history, obtain a new approval, and require a new acknowledgement when the audience’s responsibilities changed. Do not reuse the audit firm as a management approver without confirming independence.
+
+After updating the `filegrc` package, run `npx filegrc policy-library` to review optional starter updates. The command prints exact diffs and skips customized or adopted Policy content. It writes only after you accept the named proposal and exact revision with the printed `--accept`, `--proposal-revision`, and `--yes` command. Acceptance fails if the proposal changed after review. It does not approve the Policy or mark a linked Control implemented.

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

@@ -10,8 +10,7 @@
   "version": "1.0",
   "audience": [
     "employees",
-    "contractors",
-    "vendors"
+    "contractors"
   ],
   "acknowledgementRequired": true,
   "relatedDocumentIds": [