create-filegrc 0.6.5 → 0.7.1

package/template/data/documents/document-incident-response-plan.md

@@ -1,138 +0,0 @@
-# Incident Response Plan
-
-## Purpose
-
-This plan defines how {{company_name}} identifies, declares, contains, investigates, communicates, recovers from, and learns from security incidents.
-
-## Scope
-
-This plan applies to suspected or confirmed events affecting company or customer systems, data, identities, devices, facilities, vendors, or business operations. Availability disruptions may also activate the Business Continuity and Disaster Recovery Plan.
-
-Questions and incident reports should be sent immediately to {{security_contact_email}}. If that route is unavailable or may be compromised, contact the current Policy Owner through a known alternate channel.
-
-## Definitions
-
-A **security event** is an observable occurrence that may affect the confidentiality, integrity, or availability of systems or information.
-
-A **security incident** is a security event that requires coordinated investigation, containment, recovery, or communication.
-
-A **material incident** is an incident that:
-
-- Causes or is reasonably likely to cause significant harm to customers, workers, operations, systems, or data
-- Causes a significant failure to meet a service commitment or system requirement
-- Results from a material control failure
-- Requires notice to a customer, regulator, insurer, or another outside party
-- Is designated material by the incident lead or executive sponsor based on the known facts
-
-Critical and High incidents are material unless the incident lead records why they are not. A lower-severity incident may still be material.
-
-## Severity
-
-The incident lead assigns an initial severity during triage and updates it as facts change.
-
-| Severity | General criteria | Response posture |
-| --- | --- | --- |
-| Critical | Active or widespread compromise, severe customer or operational harm, major Restricted-data exposure, or an urgent external-notification duty | Immediate executive and technical coordination with continuous ownership until contained |
-| High | Confirmed unauthorized access, material production or security-control impact, significant Confidential-data exposure, or likely material incident | Immediate coordinated response and frequent leadership updates |
-| Medium | Confirmed incident with limited scope or impact that can be contained through normal response procedures | Assigned incident lead, documented response, and escalation if impact grows |
-| Low | Security event requiring investigation or corrective work with little realized impact | Assigned owner, documented resolution, and trend review where useful |
-
-Severity considers affected data, systems, customers, privileges, duration, spread, exploitability, business impact, and notification duties. Every severity change records the reason and time.
-
-## Roles and authority
-
-These names describe response 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 responds.
-
-### Reporter
-
-Anyone may report a suspected incident. Reporters preserve available evidence, stop unsafe activity when they can do so safely, and follow response instructions. They do not need proof before reporting.
-
-### Incident lead
-
-The incident lead declares the incident, assigns severity, coordinates work, maintains the incident record, approves status changes, and decides when the incident is contained and closed. The current Policy Owner acts as incident lead until another qualified person is assigned.
-
-### Technical responders
-
-Technical responders investigate, contain, preserve evidence, remove the cause, restore service, and validate affected systems under the incident lead's direction.
-
-### System and process owners
-
-Owners explain business impact, dependencies, data, customer commitments, and recovery needs. They approve restored operation and remaining risk within their authority.
-
-### Executive sponsor
-
-The executive sponsor makes decisions beyond the incident lead's authority, accepts material residual risk, and approves material external communications.
-
-### Legal, privacy, insurance, and communications owners
-
-The responsible owners assess notification duties, preserve privilege where applicable, coordinate required third parties, and approve communications within their authority.
-
-## Reporting and declaration
-
-Report suspected phishing, malware, unauthorized access, credential exposure, data loss, unintended disclosure, security-control failure, or other security harm immediately.
-
-The incident lead records:
-
-- The report, detection time, and known occurrence time
-- Affected systems, identities, data, customers, locations, and vendors
-- Initial impact, severity, and materiality decision
-- Response participants and assigned owners
-- Evidence sources and preservation actions
-- Decisions, actions, communications, and timestamps
-- Required notifications and their owners and deadlines
-- Recovery status, remaining risk, and follow-up work
-
-An event becomes an incident when the incident lead determines that coordinated response is needed. Uncertainty is not a reason to delay containment or escalation.
-
-## Response
-
-The incident lead coordinates these activities in the order appropriate to the incident:
-
-1. Validate the report and assign an initial severity.
-2. Protect people and contain continuing harm.
-3. Preserve evidence and establish a reliable incident timeline.
-4. Identify affected systems, data, identities, customers, and dependencies.
-5. Remove the cause and close the path used by the incident.
-6. Recover systems and data through approved procedures.
-7. Validate security, integrity, monitoring, and expected operation.
-8. Complete required internal and external communications.
-9. Monitor for recurrence.
-10. Close the incident after owners accept the restored state and remaining risk.
-
-Responders may take emergency action needed to contain harm. Emergency changes must be recorded and reviewed through the normal change process after service is stable.
-
-## Evidence and investigation
-
-Responders preserve relevant messages, logs, alerts, files, system images, access records, configuration, and communications. Evidence records identify the collector, source, collection time, affected system, handling method, and integrity information available from the source.
-
-Access to incident evidence is limited to people with a response, legal, privacy, insurance, or audit need. Do not put credentials, active session material, regulated personal data, or confidential third-party reports in this repository unless its access and retention rules permit them.
-
-## Communications and notification
-
-Only authorized people communicate externally on behalf of {{company_name}}. The incident lead coordinates internal updates so responders, owners, and leadership receive the facts and decisions they need.
-
-For each potential external notice, the responsible owner records:
-
-- The triggering law, contract, policy, or commitment
-- The affected audience and known facts
-- The decision-maker and communication owner
-- The deadline and the event that started the deadline
-- The decision, approval, delivery time, and retained evidence
-
-Communications distinguish confirmed facts from estimates, avoid unsupported claims, and preserve confidentiality.
-
-## Recovery and closure
-
-Recovery follows approved system objectives and the Business Continuity and Disaster Recovery Plan when coordinated continuity work is needed. Systems do not return to service until the incident lead and system owner accept their security, integrity, monitoring, and remaining risk.
-
-Closure requires a final severity and materiality decision, an incident summary, disposition of notification duties, linked evidence, and assigned follow-up work.
-
-## Review and exercises
-
-Material incidents receive a root-cause and lessons review within one week. The review records contributing conditions, control failures, recovery results, communications, corrective actions, owners, and due dates.
-
-{{company_name}} tests this plan at least annually. Exercises cover declaration, roles, escalation, evidence, communications, recovery coordination, and lessons. Each annual exercise also tests at least one representative security alert from generation through receipt, acknowledgement, escalation, and a fallback route. Record timestamps, expected and actual recipients, failed steps, findings, and follow-up work.
-
-After a material change to monitoring, alert routing, escalation contacts, or response tooling, the owner tests the affected path within 30 days or records why the change cannot affect alert delivery or response.
-
-The policy owner reviews this plan at least annually and after a material incident or material change to systems, risks, contacts, or notification duties. Git history records approvals and changes.

package/template/data/policies/policy-anti-bribery-corruption.json

@@ -1,19 +0,0 @@
-{
-  "id": "policy-anti-bribery-corruption",
-  "type": "policy",
-  "title": "Anti-Bribery and Corruption Policy",
-  "status": "draft",
-  "ownerIds": [
-    "appointment-policy-owner"
-  ],
-  "policyKind": "corporate-conduct",
-  "version": "1.0",
-  "audience": [
-    "employees",
-    "contractors",
-    "agents"
-  ],
-  "acknowledgementRequired": true,
-  "proposedEffectiveOn": "{{effective_date}}",
-  "programRole": "conditional"
-}

package/template/data/policies/policy-anti-bribery-corruption.md

@@ -1,87 +0,0 @@
-# Anti-Bribery and Corruption Policy
-
-## Purpose
-
-{{company_name}} conducts business honestly and complies with applicable anti-bribery and anti-corruption laws. No business result justifies offering, requesting, accepting, or concealing an improper payment or benefit.
-
-## Scope
-
-This policy applies to employees, contractors, officers, directors, agents, consultants, and third parties acting for {{company_name}}.
-
-## Prohibited conduct
-
-Covered persons must not directly or indirectly:
-
-- Offer, promise, authorize, give, request, or accept anything of value to improperly influence a decision.
-- Reward someone for misusing a position of trust.
-- Use a third party to do something this policy prohibits.
-- Make facilitation or expediting payments, except when necessary to prevent an immediate threat to health or safety.
-- Create false, incomplete, misleading, or undisclosed records.
-- Retaliate against someone who raises a concern in good faith.
-
-"Anything of value" includes money, gifts, meals, travel, entertainment, discounts, services, employment opportunities, charitable contributions, political contributions, and benefits provided to a recipient's family or associates.
-
-## Government officials
-
-Interactions with government officials require added care. The term includes elected and appointed officials, employees of government agencies or state-controlled entities, political candidates, public international organizations, and anyone acting in an official capacity.
-
-No payment, gift, or benefit may be offered to a government official to obtain or retain business, avoid a requirement, influence an official act, or secure an improper advantage.
-
-## Gifts, meals, travel, and entertainment
-
-Business courtesies must:
-
-- Have a legitimate business purpose.
-- Be reasonable, infrequent, and appropriate to the circumstances.
-- Comply with the recipient's rules and applicable law.
-- Never consist of cash or a cash equivalent.
-- Never be intended to influence a pending decision.
-- Be recorded accurately when {{company_name}} pays for them.
-
-The policy owner must approve any courtesy that could reasonably appear improper.
-
-## Political and charitable contributions
-
-Company funds, property, or services may not be used for political contributions without written approval from the policy owner and confirmation that the contribution is lawful.
-
-Charitable contributions must have a documented charitable purpose and may not benefit a decision-maker personally or act as a substitute for an improper payment.
-
-## Third parties
-
-Before engaging an agent, consultant, reseller, or other intermediary who may interact with customers or officials on {{company_name}}'s behalf, the responsible owner must:
-
-1. Perform risk-based due diligence.
-2. Confirm the service and compensation are commercially reasonable.
-3. Use a written agreement describing the service and requiring lawful conduct.
-4. Approve and retain invoices and supporting records.
-5. Monitor for unusual requests, payment methods, or relationships.
-
-Warning signs must be resolved before engagement or payment. Examples include:
-
-- A request for payment to an unrelated person, unusual account, or country unrelated to the work.
-- Vague services, excessive commissions, or invoices that do not match the agreement.
-- A close relationship with a government official or decision-maker.
-- Refusal to complete due diligence or sign appropriate contract terms.
-- A request to hide a person's identity, role, or the purpose of a transaction.
-
-## Books and records
-
-Transactions must be recorded promptly, accurately, and with enough detail to explain their purpose. Undisclosed accounts, false descriptions, fabricated invoices, and off-book transactions are prohibited.
-
-## Reporting
-
-Report questions, suspected violations, requests for improper payments, or inaccurate records to the current Policy Owner at {{security_contact_email}}. Reports may be made without first notifying a manager.
-
-{{company_name}} prohibits retaliation against anyone who reports a concern or participates in an investigation in good faith.
-
-## Investigations and enforcement
-
-{{company_name}} will review credible reports promptly and limit disclosure to people who need the information. Covered persons must preserve relevant records and cooperate honestly.
-
-Violations may result in removal of authority, termination of a contract or employment relationship, recovery of funds, and referral to authorities when appropriate.
-
-## Training and review
-
-People in higher-risk roles complete assigned anti-bribery training within 30 days of starting those duties or changing into a covered role. Covered roles include work involving sales, procurement, payments, gifts or hospitality, government interaction, higher-risk locations, or third parties acting for {{company_name}}. The onboarding or role-change checklist records the training assignment or why it does not apply.
-
-This policy is reviewed at least annually and after a material legal, geographic, or business change.

package/template/data/policies/policy-clear-desk-screen.json

@@ -1,18 +0,0 @@
-{
-  "id": "policy-clear-desk-screen",
-  "type": "policy",
-  "title": "Clear Desk and Clear Screen Policy",
-  "status": "draft",
-  "ownerIds": [
-    "appointment-policy-owner"
-  ],
-  "policyKind": "information-security",
-  "version": "1.0",
-  "audience": [
-    "employees",
-    "contractors"
-  ],
-  "acknowledgementRequired": true,
-  "proposedEffectiveOn": "{{effective_date}}",
-  "programRole": "alternative"
-}

package/template/data/policies/policy-clear-desk-screen.md

@@ -1,49 +0,0 @@
-# Clear Desk and Clear Screen Policy
-
-## Purpose
-
-{{company_name}} protects confidential information from accidental exposure, theft, and unauthorized access in offices, shared spaces, and remote work locations.
-
-## Scope
-
-This policy applies to employees and contractors who handle company, customer, workforce, or vendor information.
-
-## Clear desk requirements
-
-When a workspace is unattended:
-
-- Store confidential papers and removable media in a locked or access-controlled location.
-- Remove passwords, access codes, keys, badges, and authentication devices from view.
-- Do not leave payment information, identity documents, contracts, customer lists, or personnel records exposed.
-- Retrieve sensitive print jobs immediately.
-- Dispose of sensitive paper in an approved secure-destruction container.
-- Return shared meeting rooms and work areas to a clean state.
-- Secure portable equipment with a physical lock or security cable where practical.
-
-At the end of the workday, secure confidential material and company equipment.
-
-## Clear screen requirements
-
-- Lock the screen whenever leaving a device unattended.
-- Configure automatic screen locking after no more than 15 minutes of inactivity.
-- Position screens to reduce unnecessary viewing by visitors or the public.
-- Use a privacy screen when confidential information must be viewed in a public or shared location.
-- Close files and applications that are no longer needed.
-- Do not display passwords, secrets, or recovery codes on monitors or notes.
-- Do not leave sensitive files, shortcuts, diagrams, or other information exposed on a shared desktop or display.
-
-## Remote work
-
-Remote workers must choose a workspace where household members, visitors, and the public cannot casually view or access confidential information. Voice and video calls involving confidential matters must be conducted where they cannot be overheard.
-
-## Visitors
-
-Visitors must remain in authorized areas and be supervised where confidential information or systems are present. Hosts are responsible for clearing exposed information before a visitor arrives.
-
-## Lost material or suspected exposure
-
-Report lost papers, devices, badges, removable media, or suspected unauthorized viewing immediately to the current Policy Owner at {{security_contact_email}}.
-
-## Enforcement and review
-
-Failure to follow this policy may lead to access restrictions or disciplinary action. The policy owner reviews this policy at least annually.

package/template/data/policies/policy-data-protection-handling.json

@@ -1,22 +0,0 @@
-{
-  "id": "policy-data-protection-handling",
-  "type": "policy",
-  "title": "Data Protection and Handling Policy",
-  "status": "draft",
-  "ownerIds": [
-    "appointment-policy-owner"
-  ],
-  "policyKind": "information-security",
-  "version": "1.0",
-  "audience": [
-    "employees",
-    "contractors",
-    "vendors"
-  ],
-  "acknowledgementRequired": true,
-  "relatedDocumentIds": [
-    "document-data-retention-schedule"
-  ],
-  "proposedEffectiveOn": "{{effective_date}}",
-  "programRole": "required"
-}

package/template/data/policies/policy-data-protection-handling.md

@@ -1,130 +0,0 @@
-# Data Protection and Handling Policy
-
-## Purpose
-
-This policy defines how {{company_name}} classifies, accesses, uses, stores, shares, retains, and disposes of data.
-
-## Scope
-
-This policy applies to employees, contractors, vendors, systems, devices, and records that create, receive, process, store, or transmit data on behalf of {{company_name}}.
-
-## Responsibilities
-
-The current Policy Owner owns this policy. System and data owners decide which data a system may process, assign classifications, approve access, and set retention requirements. Everyone in scope must handle data according to its classification and report suspected loss or misuse.
-
-Questions and reports should be sent to {{security_contact_email}}.
-
-## Data classification
-
-Data owners assign the highest classification required by the data in a record, file, system, or transfer.
-
-| Classification | Description | Examples | Minimum handling |
-| --- | --- | --- | --- |
-| Public | Approved for public release | Published web content and public documentation | Protect integrity and use approved publishing processes |
-| Internal | Intended for the workforce and approved partners | Internal procedures and routine business records | Limit access to people with a business need |
-| Confidential | Disclosure could harm {{company_name}}, a customer, or another person | Contracts, financial records, customer data, source code, and security records | Approved systems, access control, encryption in transit and at rest, and protected sharing |
-| Restricted | Disclosure or alteration could cause severe harm or trigger legal duties | Credentials, cryptographic keys, regulated data, and highly sensitive security material | Explicit approval, least privilege, encryption in transit and at rest, and additional monitoring |
-
-When classification is uncertain, treat the data as Confidential until its owner decides.
-
-Credentials, private keys, authentication tokens, and recovery codes must be stored in an approved secrets-management system. Do not put them in source files, tickets, chat messages, policy records, or other general-purpose repositories.
-
-## Data inventory and ownership
-
-{{company_name}} maintains records of systems and important data stores. Those records identify:
-
-- An accountable owner
-- Business purpose
-- Data types and classification
-- Source and authorized recipients
-- Retention or deletion requirements
-- Important vendors and processing locations
-- Security and recovery needs
-
-Owners review their records at least annually and after a material change.
-
-## Collection and use
-
-Collect only data needed for an approved business purpose. Tell people how their personal data will be used when required. Do not reuse data for an incompatible purpose without review and approval.
-
-Access must follow least privilege. Owners approve access based on job duties, and managers or system owners review access at least quarterly for systems containing Restricted data and at least annually for other important systems.
-
-Do not browse, copy, export, or analyze data out of curiosity or for personal use.
-
-## Access approval and removal
-
-Access to Confidential or Restricted data follows this process:
-
-1. A manager or data owner requests access for a stated role and business need.
-2. The reviewer checks that the requested access is the minimum needed.
-3. The system owner or security owner approves elevated or sensitive access.
-4. An authorized administrator provisions the access and records the decision.
-5. Access changes and removals follow the same approval and recording requirements. Departures and role changes are handled promptly under the Information Security Policy.
-
-## Storage
-
-Internal, Confidential, and Restricted data must be stored in services approved for its classification. Local storage should be limited to a business need.
-
-Confidential and Restricted data must be encrypted in transit over untrusted networks and at rest in approved systems and on devices. Encryption keys and data must have separate access controls where practical.
-
-Production data must not be copied into development or test systems unless the owner approves the use and those systems meet the same protection requirements. Prefer generated or de-identified test data.
-
-Paper records containing Confidential or Restricted data must be secured when unattended and destroyed with an approved method.
-
-## Sharing and transfer
-
-Before sharing Confidential or Restricted data, verify:
-
-- The recipient and business need
-- The minimum data required
-- The recipient's authorization
-- The transfer method and destination
-- Contractual, privacy, and geographic restrictions
-
-Use approved encrypted channels. Do not send Restricted data through personal email, consumer file-sharing accounts, or unapproved messaging services.
-
-Public links must not be used for Confidential or Restricted data. Time-limit external access where the system supports it, and remove access when the business need ends.
-
-## Vendors and subprocessors
-
-Vendors that process Confidential or Restricted data must complete a security and privacy review before access begins. Contracts must state the permitted use, protection, incident notification, return or deletion, and any required audit rights.
-
-Owners review critical vendors at least annually and when the service or data use changes materially.
-
-## Retention and disposal
-
-Keep data only as long as required for its business purpose and applicable legal, contractual, tax, audit, or security needs. Data owners document retention rules for important record classes in the Data Retention Schedule.
-
-When retention ends, delete or anonymize the data through an approved process. Approved methods include cryptographic erase or secure wiping for reusable media and physical destruction, pulverization, or shredding for media that will not be reused. Choose a method suited to the medium and data classification.
-
-Disposal must cover active systems, local copies, and vendor-held data where practical. Backup copies may expire through the normal protected backup cycle if they cannot be selectively deleted.
-
-Legal holds and active investigations suspend normal deletion for the affected data.
-
-The policy owner reviews the Data Retention Schedule at least annually and within 30 days after a material change to systems, data use, vendors, contracts, or applicable duties. The schedule's approver must be separate from its owner.
-
-## Personal data requests
-
-Requests to access, correct, export, restrict, or delete personal data must be sent to the responsible privacy or legal owner. Track the request using the minimum personal data needed. This repository should use an opaque case ID and an approved-system reference when keeping the person's identity in Git would conflict with deletion duties.
-
-## Security incidents
-
-Report suspected loss, unauthorized access, unintended disclosure, or improper disposal immediately to {{security_contact_email}}. Do not delete evidence, contact affected people, or make external statements unless the incident lead authorizes it.
-
-{{company_name}} will investigate, contain, document, and notify affected parties as required by its incident process and applicable obligations.
-
-## Training and compliance
-
-Workers receive data-handling training when they join and at least annually. Additional training may be required for people who handle Restricted data.
-
-People who develop or materially change applications complete secure-development training within 30 days of starting those duties or changing into a covered role. Training covers common application risks, access control, input handling, secrets, logging, dependencies, and secure review.
-
-Violations may result in access removal, corrective action, contract remedies, or other action allowed by law and agreement.
-
-Exceptions require a documented business reason, owner, risk assessment, compensating controls, expiration date, and approval from the current Policy Owner.
-
-## Review
-
-{{company_name}} assesses data-protection risks at least annually, either as part of the information security risk assessment or as a separate assessment. The assessment covers material changes in data use, systems, vendors, contracts, and applicable duties.
-
-The policy owner reviews this policy at least annually and after a material change to data use, law, contracts, or systems. Git history records approvals and changes.

package/template/data/policies/policy-employee-handbook.json

@@ -1,21 +0,0 @@
-{
-  "id": "policy-employee-handbook",
-  "type": "policy",
-  "title": "Employee Handbook",
-  "status": "draft",
-  "ownerIds": [
-    "appointment-policy-owner"
-  ],
-  "policyKind": "workforce-conduct",
-  "version": "1.0",
-  "audience": [
-    "employees"
-  ],
-  "acknowledgementRequired": true,
-  "relatedDocumentIds": [
-    "document-employee-handbook-acknowledgement",
-    "document-employee-policy-acknowledgement"
-  ],
-  "proposedEffectiveOn": "{{effective_date}}",
-  "programRole": "conditional"
-}