create-filegrc 0.1.0

package/template/data/AGENTS.md

@@ -0,0 +1,185 @@
+# FileGRC Data Instructions
+
+These instructions apply to every file under `data/`. The root `AGENTS.md` explains the program and Git workflow. A collection-level `AGENTS.md`, when present, adds rules for that resource.
+
+## Start with discovery
+
+Treat the installed model as the authority. Do not infer a schema from a nearby JSON file because that file may use only part of the model.
+
+```sh
+npx filegrc guide --json
+npx filegrc types --json
+npx filegrc guide RESOURCE_TYPE --json
+npx filegrc list RESOURCE_TYPE --json
+npx filegrc search "TERM" --json
+```
+
+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, policy context, timing, and exact paths. Use `describe` only when you need the raw model definition.
+
+## Choose the right record
+
+- A reusable rule belongs in `policy`.
+- A testable activity that implements a rule belongs in `control`.
+- Work required on a schedule or event belongs in `obligation`.
+- A dated instance of work belongs in its activity type, such as `meeting`, `risk-assessment`, `access-review`, `vulnerability-scan`, `backup-test`, or `exercise`.
+- A fact that may change over time belongs in an inventory record, such as `person`, `system`, `asset`, `vendor`, or `access-grant`.
+- Proof belongs in `evidence`, not in an unexplained attachment.
+- Follow-up work belongs in `action-item`. A gap belongs in `finding`, a known threat belongs in `risk`, and an approved temporary departure belongs in `exception`.
+- An auditor request belongs in `audit-request`; the engagement itself belongs in `audit`.
+
+When more than one type seems plausible, run `guide` for each and choose the one whose purpose matches the requested action. Do not create a new type or field.
+
+## Create
+
+Create a model-driven draft:
+
+```sh
+npx filegrc scaffold RESOURCE_TYPE --title "Human name" > /tmp/filegrc-mutation.json
+```
+
+The scaffold is a mutation envelope:
+
+```json
+{
+  "record": {
+    "schemaVersion": 1,
+    "id": "resource-type-human-name",
+    "type": "resource-type",
+    "title": "Human name"
+  },
+  "content": {
+    "record": "# Human name\n"
+  }
+}
+```
+
+Replace every `null` and every empty required array. Keep the starting status until the work reaches the next real state. Do not use placeholder text as a compliance fact. Use IDs returned by `list` or the relationship candidates returned by `guide`.
+
+```sh
+npx filegrc create /tmp/filegrc-mutation.json
+npx filegrc validate --json
+```
+
+Creation is atomic. If JSON, Markdown, relationships, or validation fail, FileGRC rolls back the write. IDs are globally unique and immutable after commit.
+
+## Read and update
+
+```sh
+npx filegrc get RESOURCE_ID --mutation > /tmp/filegrc-mutation.json
+npx filegrc content RESOURCE_TYPE RESOURCE_ID --json
+npx filegrc references RESOURCE_ID --json
+```
+
+Edit the exported mutation, then run:
+
+```sh
+npx filegrc update RESOURCE_TYPE RESOURCE_ID /tmp/filegrc-mutation.json
+```
+
+The mutation includes the complete record, current Markdown, and revision hashes. FileGRC rejects the update if another person or agent changed either source after export. Reload and reapply the intended change instead of overwriting it.
+
+To update JSON and Markdown together, pass `{ "record": {...}, "content": {...}, "revision": "...", "contentRevisions": {...} }`. To change one Markdown slot:
+
+```sh
+npx filegrc content RESOURCE_TYPE RESOURCE_ID SLOT --write updated.md
+```
+
+Never replace a complete record with a partial JSON object. Never change `id` or `type` during an update. Preserve unknown namespaced `extensions`.
+
+## Record the substance
+
+JSON is for stable metadata used by validation, relationships, filters, schedules, and audit checks. Markdown is for the actual work: inputs, method, observations, results, rationale, decisions, exceptions, and follow-up.
+
+If `guide` marks a Markdown slot recommended, fill it before treating the deliverable as complete. Link evidence and resulting risks, findings, exceptions, or action items in JSON. Do not put a report’s entire variable structure into new JSON fields.
+
+Use explicit business dates. Git records when a file changed, but it does not replace `occurredOn`, `assessmentDate`, `reviewedOn`, `completedOn`, or similar fields.
+
+## Status changes
+
+Status is an assertion. Before moving a record to a completed, approved, implemented, reconciled, remediated, passed, verified, or closed state:
+
+1. Run `guide RESOURCE_TYPE --json` and satisfy every conditional field.
+2. Write the actual work and conclusion in Markdown when recommended.
+3. Link source systems, evidence, risks, findings, exceptions, and actions that support the result.
+4. Use the real completion or approval date.
+5. Confirm the named people performed and reviewed the work.
+
+Do not mark a control implemented because a policy says it should exist. Do not mark evidence verified because it was merely collected. Do not mark a task done without the completion record type requested by its obligation.
+
+## Delete and replace
+
+Before deletion:
+
+```sh
+npx filegrc references RESOURCE_ID --json
+```
+
+Delete only an uncommitted draft or a mistake:
+
+```sh
+npx filegrc delete RESOURCE_TYPE RESOURCE_ID --yes
+```
+
+FileGRC rejects deletion that breaks references and removes owned Markdown with the JSON. Retire, close, cancel, supersede, or replace committed records that explain historical operation.
+
+## Evidence and attachments
+
+Put attachments under the evidence record’s directory and store data-relative paths:
+
+```text
+data/evidence/evidence-example/evidence.json
+data/evidence/evidence-example/source-export.csv
+```
+
+The JSON uses `filePaths: ["evidence/evidence-example/source-export.csv"]`. Commit the evidence JSON and attachment together. Do not scatter PDFs, screenshots, exports, or signatures elsewhere in `data/`.
+
+Use the attachment command to copy a fixed file and update `filePaths` in one validated action:
+
+```sh
+npx filegrc attach EVIDENCE_ID /path/to/source-export.csv
+```
+
+It refuses symlinks, hidden destination names, and existing destination files.
+
+Remove a local attachment explicitly before deleting its evidence record:
+
+```sh
+npx filegrc detach EVIDENCE_ID source-export.csv --yes
+```
+
+FileGRC will not delete an evidence record that still has local attachments.
+
+Never invent evidence, dates, approvals, results, people, or source-system details. If a required fact is unavailable, leave the record in a non-final state and report the missing input.
+
+## Scheduled and event work
+
+```sh
+npx filegrc obligations --json
+npx filegrc complete OBLIGATION_ID completion-mutation.json
+npx filegrc trigger EVENT_TYPE --occurred-on YYYY-MM-DD --subject RESOURCE_ID --json
+npx filegrc complete-action ACTION_ITEM_ID completion-mutation.json --completed-on YYYY-MM-DD
+npx filegrc complete-event OBLIGATION_EVENT_ID --completed-on YYYY-MM-DD
+```
+
+`complete` and `complete-action` validate the expected completion type and link the new record atomically. `complete-event` refuses to close the workflow until every action has its requested proof. For hour-based deadlines use `--occurred-at` with an RFC 3339 timestamp and timezone.
+
+## Audit work
+
+```sh
+npx filegrc prepare-audit AUDIT_ID
+npx filegrc audit-readiness AUDIT_ID --json
+npx filegrc evidence-packet --audit AUDIT_ID --preview --json
+```
+
+Fix readiness errors in source records. Do not edit packet output under `.filegrc/`. A delivery-ready FileGRC packet means the management checks passed; the engagement team still judges evidence and performs the examination.
+
+## Finish every change
+
+```sh
+npx filegrc validate --json
+git diff --check
+git status --short
+git diff
+```
+
+Review every changed JSON, Markdown, and attachment. Confirm the diff contains no secrets, temporary files, source exports with prohibited data, or derived `.filegrc/` output. Make one focused commit whose message says why the compliance record changed.

package/template/data/action-items/AGENTS.md

@@ -0,0 +1,11 @@
+# Action Item Instructions
+
+An action item must point to the record that created the work. Keep the assignee, due date or policy window, blockers, completion records, and evidence explicit.
+
+For an event-generated action, do not weaken or extend its policy deadline by hand. Create the requested completion resource and close the action atomically:
+
+```sh
+npx filegrc complete-action ACTION_ITEM_ID completion-mutation.json --completed-on YYYY-MM-DD
+```
+
+FileGRC rejects the wrong completion type. Mark ordinary action items `done` only after the work occurred and the completion record or evidence is linked. Use `blocked` while a named dependency prevents work, and link that dependency with `blockingResourceIds`.

package/template/data/audit-populations/AGENTS.md

@@ -0,0 +1,13 @@
+# Audit Population Instructions
+
+Use one `audit-population` for one complete Type 2 population produced by one authoritative system and query. Split populations when different systems or queries generate the items.
+
+Reconcile after the period closes:
+
+1. Confirm the exact audit period and related controls.
+2. Select the cataloged source system whose `evidenceSourceKinds` covers the population.
+3. Export the complete population with fixed parameters and timezone.
+4. Create verified `population-export` evidence with the same source system, period, query, generation time, count, completeness check, and accuracy check.
+5. Link the export with `sourceEvidenceId`, name the reconciler, record the date and conclusion, and write the method and exceptions in Record Markdown.
+
+A zero count still needs its query, fixed export, and reconciliation. A population linked to an in-scope control cannot be marked not applicable.

package/template/data/audits/AGENTS.md

@@ -0,0 +1,21 @@
+# Audit Instructions
+
+Create one `audit` record for one engagement. Define the audit kind, framework, exact Type 1 date or Type 2 period, scope, owners, auditor, and report status from facts supplied by management or the engagement team.
+
+After the audit record has its dates:
+
+```sh
+npx filegrc prepare-audit AUDIT_ID
+npx filegrc audit-readiness AUDIT_ID --json
+```
+
+Preparation creates engagement-specific management documents and, for Type 2, population records. It does not approve documents, implement controls, reconcile populations, or create evidence.
+
+Run readiness repeatedly and fix source records. Preview the packet before writing it:
+
+```sh
+npx filegrc evidence-packet --audit AUDIT_ID --preview --json
+npx filegrc evidence-packet --audit AUDIT_ID
+```
+
+Do not state that an auditor accepted evidence, selected a sample, cleared an exception, or issued a report unless that fact came from the engagement team. FileGRC tracks management preparation; the CPA firm owns examination judgments and the report.

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

@@ -0,0 +1,29 @@
+{
+  "schemaVersion": 1,
+  "id": "document-business-continuity-disaster-recovery",
+  "type": "document",
+  "title": "Business Continuity and Disaster Recovery Plan",
+  "status": "draft",
+  "documentKind": "plan",
+  "ownerIds": ["person-policy-owner"],
+  "approverIds": ["person-independent-approver"],
+  "version": "1.0",
+  "effectiveOn": "{{effective_date}}",
+  "reviewCadence": {
+    "mode": "calendar",
+    "unit": "year",
+    "interval": 1,
+    "anchorDate": "{{effective_date}}"
+  },
+  "classification": "internal",
+  "audience": ["employees", "contractors"],
+  "acknowledgementRequired": true,
+  "controlIds": [
+    "control-policy-management",
+    "control-incident-exercise",
+    "control-backup-restoration",
+    "control-continuity-exercise"
+  ],
+  "relatedDocumentIds": ["document-incident-response-plan"],
+  "evidenceIds": []
+}

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

@@ -0,0 +1,190 @@
+# 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
+
+### Policy owner
+
+{{policy_owner_name}} 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

@@ -0,0 +1,21 @@
+{
+  "schemaVersion": 1,
+  "id": "document-contractor-policy-acknowledgement",
+  "type": "document",
+  "title": "Contractor Policy Acknowledgement",
+  "status": "draft",
+  "documentKind": "attestation-template",
+  "ownerIds": ["person-policy-owner"],
+  "approverIds": ["person-independent-approver"],
+  "version": "1.0",
+  "effectiveOn": "{{effective_date}}",
+  "reviewCadence": {
+    "mode": "calendar",
+    "unit": "year",
+    "interval": 1,
+    "anchorDate": "{{effective_date}}"
+  },
+  "classification": "internal",
+  "audience": ["contractors"],
+  "controlIds": ["control-workforce-expectations"]
+}

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

@@ -0,0 +1,24 @@
+# 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

@@ -0,0 +1,22 @@
+{
+  "schemaVersion": 1,
+  "id": "document-contractor-training-acknowledgement",
+  "type": "document",
+  "title": "Contractor Training Acknowledgement",
+  "status": "draft",
+  "documentKind": "attestation-template",
+  "ownerIds": ["person-policy-owner"],
+  "approverIds": ["person-independent-approver"],
+  "version": "1.0",
+  "effectiveOn": "{{effective_date}}",
+  "reviewCadence": {
+    "mode": "calendar",
+    "unit": "year",
+    "interval": 1,
+    "anchorDate": "{{effective_date}}"
+  },
+  "classification": "internal",
+  "audience": ["contractors"],
+  "controlIds": ["control-security-training"],
+  "relatedResourceIds": ["training-security-awareness"]
+}

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

@@ -0,0 +1,20 @@
+# 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-data-retention-schedule.json

@@ -0,0 +1,25 @@
+{
+  "schemaVersion": 1,
+  "id": "document-data-retention-schedule",
+  "type": "document",
+  "title": "Data Retention Schedule",
+  "status": "draft",
+  "documentKind": "schedule",
+  "ownerIds": ["person-policy-owner"],
+  "approverIds": ["person-independent-approver"],
+  "version": "1.0",
+  "effectiveOn": "{{effective_date}}",
+  "reviewCadence": {
+    "mode": "calendar",
+    "unit": "year",
+    "interval": 1,
+    "anchorDate": "{{effective_date}}"
+  },
+  "classification": "internal",
+  "audience": ["data-owners", "system-owners"],
+  "acknowledgementRequired": false,
+  "controlIds": [
+    "control-data-classification-inventory",
+    "control-data-retention-disposal"
+  ]
+}

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

@@ -0,0 +1,33 @@
+# Data Retention Schedule
+
+## Use
+
+This schedule records how long {{company_name}} keeps important record classes and what happens when each period ends. The policy owner and data owners must complete the organization-specific rows before approval.
+
+Retention periods may come from law, contract, tax, audit, security, or a documented business need. Use the longest applicable period, but do not keep data indefinitely without a reason.
+
+## Schedule
+
+| Record class | System or location | Owner | Trigger | Retention | End-of-period action | Authority or reason |
+| --- | --- | --- | --- | --- | --- | --- |
+| Security logs for important systems | Complete before approval | Complete before approval | Log event | At least 12 months | Delete through the approved system lifecycle | Information Security Policy |
+| Important production backups | Complete before approval | Complete before approval | Backup creation | At least 30 days | Expire through the protected backup cycle | Information Security Policy |
+| 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 | Complete before approval | Complete before approval | Complete before approval | Delete or anonymize | Contract, law, and business need |
+| Workforce and contractor records | Approved people or payroll system | Complete before approval | End of employment or services | Complete before approval | Securely delete | Employment, tax, and legal requirements |
+| Vendor and contract records | Complete before approval | Complete before approval | End of relationship or contract | Complete before approval | Securely delete | Contract, audit, and legal requirements |
+| Incident and investigation records | Approved incident and evidence systems | Incident owner | Incident closure | Complete before approval | 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, owner, trigger, period, disposal action, and authority.
+
+## 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.
+
+Any retention exception needs a reason, owner, approval, compensating safeguards, and expiration or next review date.
+
+## Review and disposal evidence
+
+Review this schedule at least annually and within 30 days after a material change to systems, data use, vendors, contracts, or applicable duties. The approver must be separate from the owner.
+
+For material disposal work, retain a record of the record class, source, date range, method, completion date, responsible person, exceptions, and verification.

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

@@ -0,0 +1,21 @@
+{
+  "schemaVersion": 1,
+  "id": "document-employee-handbook-acknowledgement",
+  "type": "document",
+  "title": "Employee Handbook Acknowledgement",
+  "status": "draft",
+  "documentKind": "attestation-template",
+  "ownerIds": ["person-policy-owner"],
+  "approverIds": ["person-independent-approver"],
+  "version": "1.0",
+  "effectiveOn": "{{effective_date}}",
+  "reviewCadence": {
+    "mode": "calendar",
+    "unit": "year",
+    "interval": 1,
+    "anchorDate": "{{effective_date}}"
+  },
+  "classification": "internal",
+  "audience": ["employees"],
+  "controlIds": ["control-workforce-expectations"]
+}

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

@@ -0,0 +1,19 @@
+# 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: ______________________________________________