create-filegrc 0.9.0 → 0.9.1

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "create-filegrc",
-  "version": "0.9.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.9.0",
+    version: "0.9.1",
     lockfileVersion: 3,
     requires: true,
     packages: {
       "": {
         name,
-        version: "0.9.0",
+        version: "0.9.1",
         dependencies: { filegrc: versionRange }
       }
     }

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/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/package.json

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