create-filegrc 0.16.5 → 0.16.7

package/package.json

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

package/src/defaults.js

@@ -210,7 +210,7 @@ const controls = [
     title: "Access review and offboarding",
     statement: "Owners review privileged and production access at least quarterly and other important access at least annually. Access ends at or before notice for involuntary or high-risk departures and within 24 hours for other departures.",
     requirements: ["CC6.2", "CC6.3"],
-    activity: "Review access populations, record decisions, and remove dormant, expired, or unneeded access.",
+    activity: "Review complete access populations, including workers and third parties with customer-data access, record decisions, and remove dormant, expired, or unneeded access.",
     controlType: "detective",
     operationMode: "manual",
     operationPattern: "mixed",
@@ -282,7 +282,7 @@ const controls = [
     title: "Endpoint protection",
     statement: "Devices that access company systems use approved configuration, encryption, screen locking, supported software, security updates, and continuous malware protection when supported.",
     requirements: ["CC6.6", "CC6.8", "CC7.1"],
-    activity: "Use continuous platform protection where supported and verify endpoint configuration, update, and compliance state on the approved risk-based schedule when periodic work is needed.",
+    activity: "Document protection coverage and approved deviations by device or platform class. Use continuous platform protection where supported and verify configuration, updates, and compliance on the approved risk-based schedule when periodic work is needed.",
     controlType: "preventive",
     operationMode: "automated",
     operationPattern: "mixed",
@@ -294,7 +294,7 @@ const controls = [
     title: "Network and remote-access security",
     statement: "The organization restricts network paths, separates production and nonproduction environments according to data and risk, protects remote access with approved encryption and authentication, and reviews material network access rules at least annually.",
     requirements: ["CC6.6", "CC6.7"],
-    activity: "Manage boundaries, environment connections, firewall rules, wireless safeguards, and remote production access.",
+    activity: "Document and verify customer and environment boundaries, approved network rules and deviations by source, wireless safeguards, and remote production access.",
     controlType: "preventive",
     operationMode: "hybrid",
     operationPattern: "mixed",
@@ -318,7 +318,7 @@ const controls = [
     title: "Vulnerability management",
     statement: "The organization monitors for vulnerabilities, chooses scan coverage and cadence based on exposure and risk, and assigns each confirmed vulnerability an approved risk-based remediation target or time-bound Exception.",
     requirements: ["CC7.1", "CC7.2", "CC7.3"],
-    activity: "Choose scan coverage and cadence, define approved risk-based remediation targets, and document time-bound Exceptions when a target cannot be met.",
+    activity: "Define scan scope and cadence, severity criteria, risk-based remediation and patch targets, and time-bound Exceptions when a target cannot be met.",
     controlType: "detective",
     operationMode: "hybrid",
     operationPattern: "mixed",
@@ -414,7 +414,7 @@ const controls = [
     title: "Vendor monitoring",
     statement: "Owners review critical and high-risk vendors at least annually and reassess affected vendors within 30 days after a material service change or incident, then track risks, findings, and follow-up work.",
     requirements: ["CC4.1", "CC9.2"],
-    activity: "Review vendor performance, assurance, recovery, access, incidents, and contract obligations.",
+    activity: "Set review intervals by Vendor risk and customer-data access. Review performance, assurance, recovery, access, incidents, and contract obligations, and reassess after material change.",
     controlType: "detective",
     operationMode: "manual",
     operationPattern: "mixed",
@@ -1157,7 +1157,7 @@ export function baselineRecordFiles(effectiveDate, starter = "security") {
       : obligation.recurrence,
     ...(obligation.window ? { window: obligation.window } : {}),
     ...(starterObligationSelector(obligation.id) ? { selector: starterObligationSelector(obligation.id) } : {}),
-    rationale: "Starter proposal derived from the linked Policy. Management must review the cadence, population, completion criteria, and timing before activation.",
+    rationale: starterObligationRationale(obligation.id),
     sourceResourceIds: [...(obligation.policyIds || [])]
   }));
   const sourceCoverageRecords = SOURCE_FAMILIES.map(([sourceFamilyId, title]) => {
@@ -1243,6 +1243,18 @@ function starterObligationSelector(obligationId) {
   } : null;
 }
 
+function starterObligationRationale(obligationId) {
+  const reviews = {
+    "obligation-quarterly-privileged-access-review": "Cover privileged and production access. Add other customer-data access only when an approved commitment or risk decision requires quarterly review.",
+    "obligation-annual-access-review": "Cover other important access, including customer-data paths not assigned to a shorter approved review schedule. Avoid counting the same access twice.",
+    "obligation-monthly-endpoint-protection-verification": "Confirm device and platform classes, protection coverage, exceptions, evidence, and whether the monthly cadence fits the approved risk decision.",
+    "obligation-annual-network-access-review": "Confirm the in-scope network and host rule sources, customer and environment boundaries, deviations, and review cadence.",
+    "obligation-quarterly-vulnerability-scan": "Confirm scan scope, severity method, remediation and patch targets, and whether exposure or a customer commitment requires a shorter cadence, such as monthly.",
+    "obligation-annual-critical-vendor-review": "Confirm the high and critical Vendor population, and set a separate review interval for other Vendors with customer-data access where needed."
+  };
+  return `Starter proposal derived from the linked Policy. Management must review the cadence, population, completion criteria, and timing before activation. ${reviews[obligationId] || ""}`.trim();
+}
+
 export async function writeBaselineRecords(target, effectiveDate, starter = "security") {
   for (const { path: relativePath, record } of baselineRecordFiles(effectiveDate, starter)) {
     const path = join(target, relativePath);

package/src/index.js

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

package/template/AGENTS.md

@@ -21,6 +21,8 @@ npx filegrc program-amendment SOURCE_RESOURCE_ID --json
 
 `program-path --next --json` gives agents the current step and first action. Use `--summary` for all five step statuses or `--current` for the current step’s page summaries, detailed guidance fields, commands, and next actions. The general guide lists every supported action and record type. A type guide adds the checks needed for that resource, including timing, required and conditional fields, current relationship candidates, JSON location, and Markdown slots.
 
+Before proposing a new process or record for a Control, inspect the current Control, its linked Policy and Markdown, Obligations, operating records, Components, and Evidence with `get`, `list`, `search`, and `references`. Read `get CONTROL_ID --workflow --json` and the relevant type guides to find the actual gap. Reuse an existing rule or workflow when it covers the requirement. If the design exists but operation is unproven, ask for the real event, actors, dates, and evidence needed to record it; do not ask management to design the process again. Ask users only for decisions or facts that the repository and available sources cannot verify. Never infer that a Policy or planned Obligation proves the Control operated.
+
 For a new record, generate a mutation envelope:
 
 ```sh
@@ -64,6 +66,8 @@ The JSON and Markdown under `data/`, the installed model, policy content, and Gi
 
 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.
 
+The workflow recommendation's `context` lists existing connected records, the work phase, and unmet checks. Open those records before following a setup prompt. A connected Policy, Obligation, or Evidence record is context; check the dated work and its proof before saying a Control operated.
+
 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.
 
 An Action Item or Audit Request is a source record because it captures a real assignment, owner, deadline, and completion proof. A Collection Review is also a source record because FileGRC cannot infer that management reviewed an apparently complete or empty collection. `npx filegrc guide RESOURCE_TYPE --json` returns the type-specific review criteria and current confirmation state. Use `npx filegrc review-collection RESOURCE_TYPE --scaffold`, fill the conclusion and reviewer facts, preview it, then apply it with `--yes`. FileGRC calculates the collection revision and marks the confirmation stale after a reviewed record or material scope fact changes.

package/template/data/AGENTS.md

@@ -18,6 +18,10 @@ npx filegrc search "TERM" --json
 
 Use `program-path --next --json` for the current lifecycle step. Use `workflow --json` when you need the full shared assessments, complete checklist, Work Items, and blockers. Use `guide` before any unfamiliar create or status transition. It reports required fields, fields required by a status, enum values, relationship types and candidates, Markdown slots, timing, and exact paths. Use `describe` only when you need the raw model definition.
 
+Before creating a record or asking for a new procedure, inspect matching records and their links with `list`, `search`, `get RESOURCE_ID --workflow --json`, and `references RESOURCE_ID --json`. Read the linked Policy and companion Markdown, Control, Obligations, operating records, Components, and Evidence as applicable. Reuse the authoritative record and update it when needed. Separate a documented design or enabled schedule from proof that work actually occurred. Ask for only the missing business facts, decisions, or external evidence that you cannot verify; do not invent an event or ask for facts already recorded here.
+
+In `get RESOURCE_ID --workflow --json`, inspect `workflow.recommended.context.existing` before using `scaffold`. The listed records are relationship candidates, not proof that work occurred.
+
 After changing a lifecycle fact directly, review `reconcile --preview --json`. A candidate asks whether the change represents a real policy event. Supply the actual event date or timestamp, departure risk when relevant, and explicit confirmation before applying it. If it is a false positive, use `reconcile --dismiss` with the exact candidate fingerprint, a Person reviewer, the review date, a rationale, and `--yes`. The immutable dismissal suppresses only that fingerprint.
 
 ## Choose the right record

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

@@ -120,6 +120,8 @@ Removable media containing Confidential or Restricted data requires owner approv
 
 The Data Retention Schedule defines the approved period and disposal method for important in-scope record classes. Supporting standards, procedures, and system records document implementation. Disposal must be suitable for the media and classification, with dated proof when the Control requires it.
 
+Owners document and test how approved deletion requests and retention cutoffs apply to primary data, derived copies, local copies, Vendor-held data, and backups. Procedures identify copies that cannot be removed immediately, their access restrictions and expiry, and any legal hold or contractual limit. Owners verify completion against the approved scope before representing data as deleted.
+
 ## Cryptography, Encryption, Key, and Secrets Management Policy
 
 ### Encryption requirements
@@ -164,6 +166,8 @@ Passwords and other authenticators must meet settings approved for the System's
 - **Customer and external-user access:** MFA is required when an approved Control, customer commitment, or risk decision requires it.
 - **Exceptions:** Where required MFA is unavailable, management must approve a time-bound Exception with a risk assessment, compensating Controls, an accountable owner, and a review or expiration date.
 
+Owners document customer authentication and workforce authentication separately for each relevant System. They record whether either path uses single sign-on, where MFA is enforced, and how access is revoked. Remote-access methods are selected and approved for the System and risk; a VPN is required only when an approved Control, commitment, or risk decision calls for one.
+
 ## Endpoint, Mobile Device, BYOD, and Malware Protection Policy
 
 ### Company devices and platform protection
@@ -194,6 +198,8 @@ Owners restrict inbound, outbound, and internal network paths and management int
 
 Production, development, test, and general-user environments must be separated to the extent needed for their data, exposure, privileges, and change risk. Connections between environments require approved paths and safeguards. Wireless and other local networks used for company work require authentication and encryption appropriate to current risk and technical capability.
 
+When a service processes data for multiple customers, owners define and enforce customer-data boundaries appropriate to the architecture. They verify that access paths and material changes preserve those boundaries, and record the test method, result, and follow-up.
+
 ## Configuration Management and System Maintenance Policy
 
 Important Systems and Components use documented secure configuration expectations based on trusted guidance, technical capability, and risk. Owners change or disable unnecessary default accounts, credentials, services, ports, features, and configurations. Deviations require review and, when material, an approved Exception.
@@ -230,6 +236,8 @@ Important Systems record and protect the security and operational events needed
 
 Logs use synchronized time, restrict alteration and access, and avoid unnecessary secrets or personal data. Each System's retention period belongs in the approved Data Retention Schedule. Owners document risk-based alerts, review paths, thresholds, and response ownership in approved standards, procedures, and schedules.
 
+When an incident may require investigation, responders preserve relevant logs and their context under the incident process, with controlled access and a documented retention or hold decision.
+
 ### Monitoring and alert testing
 
 Systems with availability commitments, recovery objectives, or material operational dependencies monitor the health, capacity, failure, and service indicators needed to detect degradation. Representative alert paths are tested from generation through acknowledgement, escalation, and fallback on the approved schedule and after a material path change. This requirement does not prescribe a particular monitoring or log-management product.

package/template/package.json

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