create-filegrc 0.6.5 → 0.7.1

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

@@ -76,9 +76,9 @@ Report a lost or stolen device, badge, authentication token, paper record, or re
 ## Identity and authentication
 
 - Use a unique identity for company work. Do not share accounts.
-- Use an approved password manager to generate and store a unique password for each account.
+- Use a unique password for each account and store it only through the credential-protection method approved for that System.
 - Prefer long, randomly generated passwords or long passphrases. Do not make predictable substitutions or reuse passwords.
-- Keep passwords, recovery codes, private keys, and authentication tokens out of email, chat, tickets, source code, and general-purpose documents.
+- Keep plaintext passwords, recovery codes, private keys, and authentication tokens out of email, chat, tickets, source code, and general-purpose documents. Approved source-controlled ciphertext must follow the Policy and keep decryption keys separate.
 - Use multi-factor authentication when required.
 - Protect authentication devices and report an unexpected prompt, lost factor, or suspected credential exposure.
 - Never disclose a password or authentication code to someone who asks for it.
@@ -92,7 +92,7 @@ Use a company-managed device for company work unless another arrangement is appr
 - Keep the operating system, browser, applications, and security tools supported and updated.
 - Enable automatic security updates when approved.
 - Keep disk encryption, screen locking, malware protection, firewall, logging, and device-management controls enabled.
-- Lock the screen whenever the device is unattended. Company devices lock automatically after no more than 15 minutes.
+- Lock the screen whenever the device is unattended. Company-managed devices must use the approved automatic-lock setting.
 - Use a standard user account for routine work. Use administrative access only when authorized and needed.
 - Install applications and browser extensions only through an approved process.
 - Do not connect unapproved removable media.
@@ -105,7 +105,7 @@ Do not wipe, reset, power off, or materially alter a suspected compromised devic
 
 - Use trusted networks or an approved encrypted connection.
 - Treat public and shared networks as untrusted.
-- Use approved remote-access methods and multi-factor authentication.
+- Use approved remote-access methods and multi-factor authentication when the Policy, Control, customer commitment, or risk decision requires it.
 - Do not discuss or display confidential information where another person can see or hear it.
 - Keep work data out of personal accounts and unapproved applications.
 - Use approved mobile applications, device encryption, screen locking, and remote lock or wipe where supported.
@@ -126,16 +126,30 @@ A secure connection protects data in transit. It does not prove that a site, sen
 
 ## Data handling
 
-Follow the Data Protection and Handling Policy and use the highest applicable classification.
+Follow the Information Security Policy and use the highest applicable classification.
 
 - Collect, access, and retain only the data needed for approved work.
 - Store company data only in approved systems.
 - Use least privilege and approved sharing settings.
 - Do not use production data in development or testing unless approved and equally protected.
-- Do not put credentials, authentication tokens, or cryptographic keys in this repository or another general-purpose system.
+- Do not put plaintext credentials, authentication tokens, or cryptographic keys in source repositories or general-purpose Systems. Approved source-controlled ciphertext must meet the Policy's separate-key, access, and rotation conditions.
 - Dispose of paper, devices, and media through an approved process.
 - Report unintended disclosure, excessive access, improper disposal, or an unexpected public link.
 
+## Building and changing systems
+
+People who design, build, review, deploy, or administer company Systems must:
+
+- Keep code, infrastructure changes, and production access in approved repositories and workflows.
+- Protect branches and deployments with the reviews, tests, and approvals required by the Change Management Control.
+- Keep plaintext secrets out of source code, build output, tickets, chat, and logs. Repository access alone must never decrypt approved source-controlled ciphertext.
+- Validate input, authorization, error handling, and sensitive-data use at trust boundaries.
+- Review new and changed dependencies, resolve security findings within the approved risk targets, and record Exceptions when a target cannot be met.
+- Separate development and production duties when practical. Record a compensating or post-deployment review when team size or urgency prevents independent pre-deployment review.
+- Record emergency changes, limit their scope, validate the result, and complete the required follow-up review.
+
+Approved supporting standards, procedures, and schedules document the tools, settings, approval paths, and evidence.
+
 ## Physical security and clear workspaces
 
 - Use your own badge, key, and authentication factor. Do not allow another person to follow you into a restricted area without authorization.

package/template/package.json

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

package/template/data/documents/document-business-continuity-disaster-recovery.json

@@ -1,29 +0,0 @@
-{
-  "id": "document-business-continuity-disaster-recovery",
-  "type": "document",
-  "title": "Business Continuity and Disaster Recovery Plan",
-  "status": "draft",
-  "documentKind": "plan",
-  "ownerIds": [
-    "appointment-policy-owner"
-  ],
-  "version": "1.0",
-  "audience": [
-    "employees",
-    "contractors"
-  ],
-  "acknowledgementRequired": true,
-  "controlIds": [
-    "control-policy-management",
-    "control-incident-exercise",
-    "control-backup-restoration",
-    "control-continuity-exercise"
-  ],
-  "relatedDocumentIds": [
-    "document-incident-response-plan"
-  ],
-  "evidenceIds": [],
-  "classificationId": "internal",
-  "proposedEffectiveOn": "{{effective_date}}",
-  "programRole": "required"
-}

package/template/data/documents/document-business-continuity-disaster-recovery.md

@@ -1,192 +0,0 @@
-# Business Continuity and Disaster Recovery Plan
-
-## Purpose
-
-This plan describes how {{company_name}} will respond to a disruption, continue its most important work, recover systems and data, and return to normal operations.
-
-## Scope
-
-This plan applies to the people, systems, facilities, vendors, and business processes needed to deliver {{company_name}} products and services. It covers events that materially affect availability, including:
-
-- Cloud or hosting failures
-- Software defects and failed deployments
-- Cybersecurity incidents
-- Loss of data or access to data
-- Utility, network, or workplace outages
-- Unavailability of a key vendor or workforce member
-- Natural disasters and other regional events
-
-Security incidents follow the incident response requirements in the Information Security Policy. A single event may activate both processes.
-
-## Objectives
-
-During a disruption, {{company_name}} will:
-
-1. Protect people.
-2. Limit harm to customers, systems, and data.
-3. Maintain or restore critical work within approved recovery targets.
-4. Communicate accurate information to affected parties.
-5. Preserve evidence needed for investigation and review.
-6. Record lessons and assign follow-up work.
-
-## Roles
-
-These names describe recovery functions, not required job titles or separate Appointments. The current Policy Owner performs them by default and management delegates a function only when that matches how the organization actually recovers its services.
-
-### Policy owner
-
-The current Policy Owner owns this plan and keeps it current. The Policy Owner may delegate response duties but remains accountable for the plan.
-
-### Security and risk oversight
-
-The security and risk oversight group reviews the plan, material disruptions, annual exercise results, and unresolved continuity risks. Its review is recorded in formal meeting minutes.
-
-### Incident lead
-
-The incident lead coordinates the response, assigns work, maintains the incident record, approves status changes, and decides when normal operations have resumed. The policy owner acts as incident lead until another qualified person is assigned.
-
-### Executive sponsor
-
-The executive sponsor makes business-priority decisions that exceed the incident lead's authority and approves material external communications.
-
-### Technical recovery lead
-
-The technical recovery lead coordinates system restoration, data recovery, technical validation, and vendor escalation.
-
-### System and process owners
-
-Owners assess impact, recover their systems or processes, validate restored service, and keep recovery instructions current.
-
-### Continuity team
-
-The continuity team carries out assigned business, technical, customer, vendor, and communications tasks. Membership may change with the event.
-
-### Workforce members
-
-Employees and contractors must report suspected disruptions promptly, follow response instructions, and avoid uncoordinated changes that could make recovery harder.
-
-## Activation
-
-Anyone may report a disruption to {{security_contact_email}}. The policy owner or incident lead activates this plan when normal operating procedures cannot restore an important service within its expected time or when coordinated business action is needed.
-
-The incident lead records:
-
-- What happened and when it was detected
-- Affected services, data, customers, locations, and vendors
-- Current business and security impact
-- Response owner and participants
-- Decisions, actions, communications, and timestamps
-- Recovery status and remaining risks
-
-## Recovery priorities and objectives
-
-System and process owners define recovery objectives from business impact rather than assigning a universal target to a severity label. Each important system or process records:
-
-- Its business priority and maximum tolerable downtime
-- Its recovery time objective
-- Its recovery point objective
-- The people, systems, vendors, facilities, and data it depends on
-- Minimum staffing, access, and communications needed for recovery
-- Available manual workarounds or alternate services
-- The owner responsible for validating recovery
-
-The incident lead normally restores Critical work before High, Medium, and Low work. The incident lead may change that order to protect people, contain security harm, preserve data integrity, meet a legal or contractual deadline, or unblock another recovery.
-
-The approved objective recorded for each affected system or process is the recovery target. If no approved objective exists, the incident lead sets and records an interim target based on business impact and dependencies. The owner must formalize the missing objective as follow-up work.
-
-Recovery timing starts when the disruption began when that time is known. If it is not known, the incident record uses the earliest confirmed time and states that limitation.
-
-## Response and recovery
-
-The incident lead coordinates these steps in the order appropriate to the event:
-
-1. Confirm the event and protect people.
-2. Identify affected systems, data, processes, and dependencies.
-3. Contain the cause and prevent additional harm.
-4. Activate manual procedures, alternate services, or remote work when available.
-5. Recover systems and data in priority order.
-6. Validate security, integrity, and expected operation before resuming normal use.
-7. Communicate status to affected parties.
-8. Monitor the recovered service for recurrence.
-9. Close the event after owners accept the restored state and remaining risk.
-
-Responders must record material decisions and actions as they occur. Emergency changes must be reviewed through the normal change process after service is stable.
-
-## Communication
-
-The incident lead chooses the audience, channel, and frequency based on impact.
-
-Internal updates should state what is known, what remains uncertain, who is responsible, and when the next update is expected. Only authorized people may communicate externally on behalf of {{company_name}}.
-
-When customers are affected, the incident lead identifies the applicable contractual commitments, legal duties, and approved communications plan, then records the audience, owner, and deadline for the initial update. When no fixed deadline applies, {{company_name}} communicates promptly after confirming enough facts to provide an accurate and useful update.
-
-Customer, regulator, insurer, or law-enforcement notifications must be reviewed by the people responsible for legal, contractual, privacy, and communications obligations. Notifications must meet applicable deadlines and avoid unsupported claims.
-
-Employees receive the disruption status, work instructions, available recovery estimate, and next expected update through one or more approved channels. The continuity team keeps an alternate contact method for use when ordinary company communications are unavailable.
-
-Owners of affected vendor relationships contact the vendor through the fastest available approved channel, coordinate restoration steps, and record material commitments and updates.
-
-## Data backup and restoration
-
-Owners of systems that store important data must:
-
-- Define backup scope and frequency that meet the system recovery point objective.
-- Protect backups from unauthorized access and changes.
-- Keep recovery access separate from ordinary user access where practical.
-- Monitor backup jobs and address failures.
-- Test restoration at least annually.
-- Record the test date, scope, result, evidence, and follow-up work.
-
-A successful backup job is not proof of recoverability. Restore tests must confirm that data can be retrieved and used.
-
-During recovery, people take priority over data or equipment. When it is safe to proceed, authorized responders assess the integrity and usability of available electronic and paper records. They may restore approved backups, use intact replicas, rebuild from reviewed configuration or source, use an approved alternate service, or recover other safeguarded copies. The restored environment must receive the same backup and security protections required for normal operation.
-
-## Specific disruption procedures
-
-### Hosted service or vendor outage
-
-The owner confirms vendor status, opens a support case when appropriate, assesses alternate service options, and tracks contractual notification and recovery commitments.
-
-### Failed deployment or software defect
-
-The owner stops further deployment, rolls back or applies an approved corrective change, validates data integrity, and monitors the restored version.
-
-### Loss of workplace access
-
-Workers use approved remote-work procedures or an approved alternate location. The incident lead confirms access to required systems, contact methods, and records.
-
-### Loss of a key workforce member
-
-The responsible manager reassigns urgent duties, obtains access through approved recovery procedures, and records any missing documentation or concentration risk as follow-up work.
-
-### Cybersecurity event
-
-Responders protect evidence and coordinate containment with recovery. Systems must not return to service until the incident lead and system owner accept the security risk.
-
-## Plan access
-
-The current plan is stored in this repository. The policy owner must ensure that people who may lead recovery can access an approved copy when the primary systems or identity provider are unavailable. Emergency contacts and access instructions must be stored in an approved protected location and must not be committed to this repository if they contain secrets.
-
-The policy owner reviews the emergency contact list at least annually and after a material personnel or vendor change.
-
-Employees receive this plan after approval and after a material update. Suppliers, customers, and other parties receive the parts needed to coordinate recovery when appropriate.
-
-## Exercises and maintenance
-
-{{company_name}} tests this plan at least annually and after a material change when the existing test no longer represents the environment. An exercise may be a tabletop scenario, technical recovery test, communication test, or combined exercise.
-
-Each exercise records:
-
-- Scenario and scope
-- Participants and roles
-- Systems and processes tested
-- Recovery objectives evaluated
-- Expected and actual results
-- Evidence
-- Findings, owners, and due dates
-
-The security and risk oversight group reviews the annual exercise and records its conclusions in meeting minutes.
-
-After this plan is activated for a real disruption, the incident lead completes a root-cause and lessons review within one week. The review identifies follow-up work, owners, and due dates.
-
-The policy owner reviews this plan at least annually and after a major disruption. Git history records approvals and changes.

package/template/data/documents/document-contractor-policy-acknowledgement.json

@@ -1,20 +0,0 @@
-{
-  "id": "document-contractor-policy-acknowledgement",
-  "type": "document",
-  "title": "Contractor Policy Acknowledgement",
-  "status": "draft",
-  "documentKind": "attestation-template",
-  "ownerIds": [
-    "appointment-policy-owner"
-  ],
-  "version": "1.0",
-  "audience": [
-    "contractors"
-  ],
-  "controlIds": [
-    "control-workforce-expectations"
-  ],
-  "classificationId": "internal",
-  "proposedEffectiveOn": "{{effective_date}}",
-  "programRole": "conditional"
-}

package/template/data/documents/document-contractor-policy-acknowledgement.md

@@ -1,24 +0,0 @@
-# Contractor Policy Acknowledgement
-
-I acknowledge that I received access to the following {{company_name}} documents:
-
-- Anti-Bribery and Corruption Policy
-- Business Continuity and Disaster Recovery Plan
-- Clear Desk and Clear Screen Policy
-- Data Protection and Handling Policy
-- Information Security Policy
-- Mobile Computing and Communications Policy
-
-I understand that I am responsible for following these documents while performing services for {{company_name}}, protecting information made available to me, and reporting suspected violations.
-
-I understand that the documents may be updated. When {{company_name}} requires a new acknowledgement, I will review the identified revisions before signing. The Git commit below identifies the exact revisions covered by this acknowledgement.
-
-This acknowledgement supplements and does not replace the applicable services, confidentiality, or data-protection agreement.
-
-Content Git commit: ___________________________________
-
-Contractor name: ____________________________________
-
-Signature: __________________________________________
-
-Date: ______________________________________________

package/template/data/documents/document-contractor-training-acknowledgement.json

@@ -1,23 +0,0 @@
-{
-  "id": "document-contractor-training-acknowledgement",
-  "type": "document",
-  "title": "Contractor Training Acknowledgement",
-  "status": "draft",
-  "documentKind": "attestation-template",
-  "ownerIds": [
-    "appointment-policy-owner"
-  ],
-  "version": "1.0",
-  "audience": [
-    "contractors"
-  ],
-  "controlIds": [
-    "control-security-training"
-  ],
-  "trainingIds": [
-    "training-security-awareness"
-  ],
-  "classificationId": "internal",
-  "proposedEffectiveOn": "{{effective_date}}",
-  "programRole": "conditional"
-}

package/template/data/documents/document-contractor-training-acknowledgement.md

@@ -1,20 +0,0 @@
-# Contractor Training Acknowledgement
-
-I acknowledge that I completed the following {{company_name}} training:
-
-- Security Awareness and Incident Response Training
-- Other assigned training: ______________________________
-
-I understand the security responsibilities and reporting process described in the training. I had an opportunity to ask questions, and I will follow the policies and procedures that apply to the services I perform.
-
-I understand that training and policies may be updated. When {{company_name}} assigns revised or additional training, I will review the identified material and complete the required acknowledgement. The Git commit below identifies the exact training revision covered by this acknowledgement.
-
-This acknowledgement supplements and does not replace the applicable services, confidentiality, data-protection, or other written agreement.
-
-Training Git commit: __________________________________
-
-Contractor name: ____________________________________
-
-Signature: __________________________________________
-
-Date: ______________________________________________

package/template/data/documents/document-employee-handbook-acknowledgement.json

@@ -1,20 +0,0 @@
-{
-  "id": "document-employee-handbook-acknowledgement",
-  "type": "document",
-  "title": "Employee Handbook Acknowledgement",
-  "status": "draft",
-  "documentKind": "attestation-template",
-  "ownerIds": [
-    "appointment-policy-owner"
-  ],
-  "version": "1.0",
-  "audience": [
-    "employees"
-  ],
-  "controlIds": [
-    "control-workforce-expectations"
-  ],
-  "classificationId": "internal",
-  "proposedEffectiveOn": "{{effective_date}}",
-  "programRole": "conditional"
-}

package/template/data/documents/document-employee-handbook-acknowledgement.md

@@ -1,19 +0,0 @@
-# Employee Handbook Acknowledgement
-
-I acknowledge that I received access to the current {{company_name}} Employee Handbook.
-
-I understand that I am responsible for reading the handbook, asking questions when a requirement is unclear, and following the requirements that apply to my work.
-
-I understand the reporting routes and the prohibition on retaliation for a good-faith report, accommodation request, safety concern, pay concern, or participation in a review.
-
-I understand that the handbook is not an employment contract. Local law, written employment terms, benefit plans, and approved regional supplements control when they differ from the handbook.
-
-I understand that the handbook may be updated. When {{company_name}} requires a new acknowledgement, I will review the identified revision before signing. The Git commit below identifies the exact handbook revision covered by this acknowledgement.
-
-Handbook Git commit: __________________________________
-
-Employee name: ______________________________________
-
-Signature: __________________________________________
-
-Date: ______________________________________________

package/template/data/documents/document-employee-policy-acknowledgement.json

@@ -1,20 +0,0 @@
-{
-  "id": "document-employee-policy-acknowledgement",
-  "type": "document",
-  "title": "Employee Policy Acknowledgement",
-  "status": "draft",
-  "documentKind": "attestation-template",
-  "ownerIds": [
-    "appointment-policy-owner"
-  ],
-  "version": "1.0",
-  "audience": [
-    "employees"
-  ],
-  "controlIds": [
-    "control-workforce-expectations"
-  ],
-  "classificationId": "internal",
-  "proposedEffectiveOn": "{{effective_date}}",
-  "programRole": "conditional"
-}

package/template/data/documents/document-employee-policy-acknowledgement.md

@@ -1,24 +0,0 @@
-# Employee Policy Acknowledgement
-
-I acknowledge that I received access to the following {{company_name}} documents:
-
-- Anti-Bribery and Corruption Policy
-- Business Continuity and Disaster Recovery Plan
-- Clear Desk and Clear Screen Policy
-- Data Protection and Handling Policy
-- Information Security Policy
-- Mobile Computing and Communications Policy
-
-I understand that I am responsible for reading and following these documents, asking questions when a requirement is unclear, and reporting suspected violations.
-
-I understand that the documents may be updated. When {{company_name}} requires a new acknowledgement, I will review the identified revisions before signing. The Git commit below identifies the exact revisions covered by this acknowledgement.
-
-This acknowledgement does not change the terms of employment or create a contract where one does not otherwise exist.
-
-Content Git commit: ___________________________________
-
-Employee name: ______________________________________
-
-Signature: __________________________________________
-
-Date: ______________________________________________

package/template/data/documents/document-employee-training-acknowledgement.json

@@ -1,23 +0,0 @@
-{
-  "id": "document-employee-training-acknowledgement",
-  "type": "document",
-  "title": "Employee Training Acknowledgement",
-  "status": "draft",
-  "documentKind": "attestation-template",
-  "ownerIds": [
-    "appointment-policy-owner"
-  ],
-  "version": "1.0",
-  "audience": [
-    "employees"
-  ],
-  "controlIds": [
-    "control-security-training"
-  ],
-  "trainingIds": [
-    "training-security-awareness"
-  ],
-  "classificationId": "internal",
-  "proposedEffectiveOn": "{{effective_date}}",
-  "programRole": "conditional"
-}

package/template/data/documents/document-employee-training-acknowledgement.md

@@ -1,20 +0,0 @@
-# Employee Training Acknowledgement
-
-I acknowledge that I completed the following {{company_name}} training:
-
-- Security Awareness and Incident Response Training
-- Other assigned training: ______________________________
-
-I understand the security responsibilities and reporting process described in the training. I had an opportunity to ask questions, and I will follow the policies and procedures that apply to my work.
-
-I understand that training and policies may be updated. When {{company_name}} assigns revised or additional training, I will review the identified material and complete the required acknowledgement. The Git commit below identifies the exact training revision covered by this acknowledgement.
-
-This acknowledgement confirms completion of assigned training. It does not create an employment contract or change written employment terms.
-
-Training Git commit: __________________________________
-
-Employee name: ______________________________________
-
-Signature: __________________________________________
-
-Date: ______________________________________________