create-filegrc 0.6.5 → 0.7.1

package/src/index.js

@@ -440,7 +440,7 @@ The generated workspace starts with foundational program records:
 
 - Workspace and renderer settings
 - The initial active owner
-- The two core Appointment records: an active Policy Owner plus a planned Independent Policy Reviewer assignment. Create another Appointment only when management actually delegates a named responsibility.
+- The two core Appointment records: an active Policy Owner plus a planned Independent Policy Reviewer assignment. Create another Appointment only when the company actually delegates a named responsibility.
 - A planned security and risk oversight team that still needs an independent chair
 - The filegrc Git repository as a governance system of record
 - A default 5x5 risk method and Public, Internal, Confidential, and Restricted data classifications
@@ -469,23 +469,24 @@ The generated workspace starts with the SOC 2 Security category:
 - Active framework records for the 2017 Trust Services Criteria with revised points of focus (2022) and the 2018 SOC 2 Description Criteria with revised implementation guidance (2022)
 - The 33 Common Criteria reference IDs from CC1.1 through CC9.2, without the licensed criteria text
 - The nine Description Criteria reference IDs from DC1 through DC9, without the licensed criteria text
-- Planned controls mapped to those references and the included policies
-- The two core Appointment records. Policy Owner starts active; Independent Policy Reviewer remains Ready until assigned. Program coordination, incident, recovery, executive, legal, privacy, insurance, communications, and audit-coordination functions stay with the Policy Owner unless management delegates one through a custom Appointment.
+- Planned controls mapped to those references and one required Information Security Policy
+- The two core Appointment records. Policy Owner starts active; Independent Policy Reviewer remains Ready until assigned. The Policy Owner coordinates incident, recovery, executive, communications, audit, insurance, privacy, and legal input unless the company delegates a function through a custom Appointment. FileGRC does not require in-house counsel or a standing legal retainer.
 - A security and risk oversight team chaired by an independent reviewer who may be internal or external
-- Recurring obligations for the reviews, scans, tests, training, and meetings required by the included policies
+- One Security Awareness Training record and proposed recurring obligations for reviews, scans, tests, training, and meetings
+- One combined Security Incident and Recovery Plan plus a focused Data Retention Schedule
 - A default 5x5 risk method and Public, Internal, Confidential, and Restricted data classifications
 
-Treat every planned control as a proposal until its owner, actual procedure in Record Markdown, system scope, cadence, authoritative evidence sources, implementation date, and mappings match actual practice. For a control linked to filegrc obligations, every non-retired Work Queue schedule must be enabled and its governing policies effective. Marking the control implemented starts eligible schedules. Do not mark a control implemented because a policy describes it. Add Availability, Processing Integrity, Confidentiality, or Privacy criteria only when they are in scope.
+Treat every planned Control as a proposal until its owner, actual procedure in Record Markdown, System scope, cadence, authoritative evidence sources, implementation date, and mappings match actual practice. FileGRC does not infer implementation from Policy prose. Enable the applicable Work Queue schedules during implementation; they remain dormant until the Policy is active and effective. Add Availability, Processing Integrity, Confidentiality, Privacy, employment, anti-bribery, or other broader GRC records only when the company chooses to expand the scope.
 
-The recurring obligations mirror the fixed cadences in the starter policies. They remain proposals until every governing policy is active and effective and, when they name controls, at least one linked control is implemented. Update the policy, control, and obligation together when an approved cadence changes. Create separate completion records, such as meetings, reviews, scans, tests, exercises, and attestations, for each period.`,
+The recurring Obligations contain reviewable starter defaults. They remain proposed until the company confirms their scope, owner, cadence, and proof. Enabling a schedule accepts those operational facts but does not start occurrences until the Information Security Policy is active and effective. Create separate completion records, such as meetings, reviews, scans, tests, exercises, and attestations, for each period.`,
     audit_preparation_guidance: "Preparation creates a separate system description, management assertion, and management representation document for the engagement from the local starter templates. Type 2 preparation also creates a period completeness statement and one `audit-population` record for each standard population. It is safe to run again and does not approve documents, mark controls implemented, or create evidence. Do not reuse one completed management document across engagements.",
     starter_setup: `## Finish initial setup
 
-The starter policies, controls, and obligations are proposals. They do not state that ${companyName} operates the described controls.
+The starter Policy, Controls, plan, schedule, training, and Obligations are proposals. They do not state that ${companyName} operates the described Controls.
 
 1. Run \`npx filegrc setup\` for guided service and goal setup, or use browser onboarding. Then finish Step 1 by adding the real reviewers and operators, finishing the oversight team, and confirming applicable criteria, commitments, material vendors, and in-scope systems.
-2. Review the starter policies, appoint a reviewer who is separate from the policy owner, and activate only the policies that match current practice. The reviewer will usually be another person in the organization, but may be external.
-3. Review the starter control set and implement each applicable Control with its actual procedure, scope, cadence, and authoritative evidence source Systems. Confirm every source is active, has the required evidence role and current access owners, and includes repeatable retrieval instructions in Record Markdown. Add the implementation date, confirm any linked Work Queue schedules are enabled, then record any complementary customer or subservice controls.
+2. Tailor the Information Security Policy and have someone other than its owner approve it. Approval accepts the Policy but does not mean the Controls are implemented.
+3. Review the starter Control set, combined Security Incident and Recovery Plan, Data Retention Schedule, Security Awareness Training, and proposed Obligations. Implement each applicable Control with its actual procedure, scope, cadence, Components, and authoritative evidence sources. Enable the applicable schedules, review the Policy activation assessment, then activate the Policy at the real implementation cutover.
 4. Run \`npx filegrc program-readiness --require-ready\`, record the management candidate period start when reliable evidence collection begins, maintain risk assessments and risks, update controls when needed, use Work Queue for scheduled work, and trigger Policy Events when changes create required actions.
 5. Engage a CPA firm, record the separate firm-agreed period in an audit record, review filegrc Evidence and External Evidence, and prepare fieldwork.`
   };
@@ -522,13 +523,13 @@ async function runCombinedSetup(target, input) {
 async function writeMinimalLockfile(target, name, versionRange) {
   const lock = {
     name,
-    version: "0.6.5",
+    version: "0.7.1",
     lockfileVersion: 3,
     requires: true,
     packages: {
       "": {
         name,
-        version: "0.6.5",
+        version: "0.7.1",
         dependencies: { filegrc: versionRange }
       }
     }

package/template/AGENTS.md

@@ -49,7 +49,7 @@ Read `data/AGENTS.md` before changing records. More specific instructions inside
 - Put policies, plans, charters, procedures, meeting minutes, training, assertions, narratives, templates, and audit responses in Markdown beside their JSON records. filegrc derives the Markdown name, so records do not contain file paths.
 - Put signed forms, screenshots, third-party reports, and immutable exports behind evidence records. These files may be PDF, image, CSV, or another fixed format.
 - Never fetch an external evidence reference automatically.
-- Do not store secrets, credentials, session data, or personal data that may need to be erased from Git history.
+- Do not store plaintext credentials, private keys, tokens, recovery codes, session data, or personal data that may need to be erased from Git history. Source-controlled ciphertext is allowed only under the Information Security Policy's approved encryption, separate-key, access, and rotation conditions.
 - Keep the editable local server on loopback or behind trusted authentication. Use the read-only static build for audit sharing.
 
 ## Source truth and derived workflow
@@ -206,9 +206,14 @@ npx filegrc program-readiness --require-ready --summary --json
 The Evidence Ready gate requires:
 
 1. A management goal, selected systems, criteria, and controls.
-2. Active policies with completed text, separate management approval, real approval and effective dates, and linked controls.
-3. Implemented Controls with an owner, actual procedure, scope, operation pattern, mappings, implementation date, and every required linked Work Queue schedule running.
-4. Every selected Control mapped to active authoritative Systems with the required evidence source roles, current access owners, and repeatable extraction instructions in Record Markdown.
+2. Policy content approved by someone other than its owner in Step 2, followed by active Policies with real effective dates at the Step 3 cutover.
+3. Implemented Controls with an owner, actual procedure, scope, operation pattern, mappings, implementation date, and every required linked Work Queue schedule enabled.
+4. Every selected Control mapped to active authoritative Components with the required evidence source roles, current access owners, and repeatable extraction instructions in Record Markdown.
+5. Required governed plans complete and active, with no unresolved activation blockers.
+
+A Policy says what the company commits to do by the date it takes effect. Approval means the company accepts those commitments. It does not prove the work is done. Controls and operating records describe how the company meets them and provide the proof. A Control may be implemented against an approved inactive Policy, and enabled Obligations remain dormant until that Policy is active and effective.
+
+Review `policyActivations` in Program Readiness before cutover. It shows planned or partial Controls, missing Components or evidence sources, missing schedules, unresolved Exceptions, and dates that need attention. At the end of Step 3, use the Controls-page review or `npx filegrc activate-policies --scaffold` to choose which approved Policies take effect. You can activate with a documented gap or approved Exception, but Evidence Readiness remains incomplete until every required Policy is active and operating. FileGRC does not infer technical implementation from Policy prose. Put configuration facts in Controls, Components, Systems, governed schedules, and Evidence.
 
 Onboarding does not create Evidence Artifacts. Complete authoritative source Components as part of Control implementation. For every incomplete family in Program Readiness, update the Control with its authoritative `evidenceSourceComponentIds`, then give each source Component the required evidence role, current access owners, and repeatable retrieval instructions in Record Markdown. Use `npx filegrc evidence-map --json` when you want only those source checks. During Step 4, create an Evidence Artifact only when a real artifact exists. Select its `sourceComponentId`, attach or reference the result, link the Controls and operating record it supports, record its collector and Classification, then have another person verify it before audit use.
 
@@ -228,7 +233,11 @@ npx filegrc audit-readiness audit-2026-type-2
 npx filegrc audit-readiness audit-2026-type-2 --require-ready --json
 ```
 
-The audit record’s `typeOneAsOf`, `periodStart`, and `periodEnd` are the dates agreed with the CPA firm. Keep the workspace candidate dates even when the formal period differs.
+The audit record’s `coverage` object stores the dates agreed with the CPA firm. Use `{ "kind": "as-of", "on": "YYYY-MM-DD" }` for Type 1 or `{ "kind": "range", "startsOn": "YYYY-MM-DD", "endsOn": "YYYY-MM-DD" }` for Type 2. Keep the Program candidate coverage even when the formal date or period differs.
+
+After reviewing the engagement's Program, Systems, criteria, Controls, commitments, subservices, complementary controls, and signatories, record the reviewed Git commit in `scopeRevision`. Update that value only after another complete scope review.
+
+Select a framework containing the complete CC1.1 through CC9.2 Security Common Criteria set, all nine SOC 2 Description Criteria, and any optional Trust Services Categories in scope. Treat every Security Common Criterion as applicable and include Controls that cover every applicable selected Trust Services criterion. For an included optional category, keep a criterion in the framework when management judges it not relevant and record the limited circumstances under DC8. Do not omit a Description Criterion. Record whether subservice organizations are identified in `subserviceConclusion` and explain the decision. If they are identified, use `subserviceTreatments` to connect each Vendor to its supplied Components inside a selected System and record the carve-out or inclusive method and rationale. An inclusive treatment also requires selected Controls linked to those Components.
 
 {{audit_preparation_guidance}}
 
@@ -239,7 +248,9 @@ Review both evidence paths against the exact firm-agreed date or period:
 
 Audit Readiness reports coverage for both paths. The packet includes the matching filegrc records and Markdown with Git history, plus Evidence Artifacts, retained attachments, delivery indexes, and checksums.
 
-Near the end of fieldwork, link a verified fixed-format copy of the signed management representation letter to its engagement-specific document. Date it on or after the Type 1 date or Type 2 period end. A representation that is still marked for later blocks packet delivery.
+Near the end of fieldwork, link a verified fixed-format copy of the signed management representation letter to its engagement-specific document. Record the actual signing timestamp in the Evidence `businessEventAt` field. It must be on or after the Type 1 date or Type 2 period end and must match the CPA report date once `reportDate` is known. A representation that is still marked for later blocks packet delivery.
+
+When the CPA firm issues the report, retain it as verified `third-party-report` Evidence with `artifactSubtype: "soc2-report"` and link that exact Evidence record through `reportEvidenceId`. A draft, screenshot, unrelated business record, or unverified file does not establish report issuance.
 
 Catalog each authoritative source as a Component and assign its `evidenceSourceKinds`. A third-party application is a Component when it supports a bounded System, a Control, Evidence, or relevant operations. Create a separate Vendor for its provider and connect the Component through `vendorId`; keep contracts, due diligence, and supplier risk on the Vendor. Name the people who can access reports and keep extraction instructions in the Component's Record Markdown. For each Type 2 population, select one source Component and export the exact audit period. Split a population when different Components or queries produce its items. Link a verified `population-export` Evidence Artifact that names the same source Component and stores the query or report parameters, generation time, timezone, count, completeness check, and accuracy check. A zero count still requires the source export and query. A population linked to an in-scope Control cannot be marked not applicable.
 

package/template/README.md

@@ -40,12 +40,16 @@ Detached and feature-branch checkouts are read-only in the browser by default. D
 ![filegrc SOC 2 program overview](docs/filegrc-home.png)
 
 1. **Define scope.** Set program ownership, choose the criteria, and define the service, Systems, and providers in scope.
-2. **Approve policies.** Turn the starter policy set into approved rules that match how the organization works.
-3. **Implement controls.** Define how each control works, where its evidence comes from, and whether customers or providers have responsibilities.
+2. **Approve policies.** Tailor the Policy, then have someone other than its owner approve the exact content. Approval does not mean the linked Controls are implemented.
+3. **Implement controls.** Define how each Control works, where its Evidence comes from, enable its schedules, and complete governed plans. Then review the approved Policies together and activate the selected cutover set.
 4. **Operate the program.** Run scheduled and event-driven work, maintain risk, and retain dated evidence.
 5. **Audit.** Set up the CPA engagement, support fieldwork, and prepare the evidence packet.
 
-Control implementation includes evidence-source readiness. Use `npx filegrc program-readiness --json` to find incomplete Control or Component records. `npx filegrc evidence-map --json` remains available as a focused diagnostic. Create an Evidence Artifact during Step 4 only when a real export, report, screenshot, signed file, or approved external reference exists.
+A Policy says what the company commits to do by the date it takes effect. Approval means the company accepts those commitments. It does not prove the work is done. Controls and operating records describe how the company meets them and provide the proof.
+
+FileGRC does not infer technical implementation from Policy prose. Configuration facts belong in Controls, Components, Systems, governed schedules, and Evidence. A Control may be implemented while its governing Policy is approved but inactive. Enabled Obligations remain dormant until the Policy is active and effective.
+
+Control implementation includes evidence-source and schedule readiness. Use `npx filegrc program-readiness --json` to review incomplete Control or Component records and each per-Policy activation assessment. At the end of Step 3, use the Controls-page review or `npx filegrc activate-policies --scaffold` to choose which approved Policies take effect. You can activate with a documented gap or approved Exception, but Evidence Readiness still requires active Policies, implemented Controls, configured evidence sources, and enabled schedules before the candidate period can begin. `npx filegrc evidence-map --json` remains available as a focused diagnostic. Create an Evidence Artifact during Step 4 only when a real export, report, screenshot, signed file, or approved external reference exists.
 
 The Program Overview shows what is done, what is blocked, and what to do next.
 
@@ -53,14 +57,16 @@ The Program Overview shows what is done, what is blocked, and what to do next.
 
 - **Work Queue** turns policy schedules and follow-up into upcoming, blocked, due, and overdue work, with named blockers when a task cannot proceed.
 - **Policy Events** create the right tasks for hiring, departures, incidents, vendor changes, and other events.
-- **Program Readiness** checks whether management can begin a reliable evidence period.
+- **Program Readiness** checks whether you can begin a reliable evidence period.
 - **Period Health** checks role, policy, control, source, obligation, and Git-history continuity across candidate and formal Type 2 dates.
 - **Audit Readiness** checks the engagement, period, documents, evidence, and Type 2 populations.
 - **Evidence packets** collect the scoped records, attachments, history, indexes, and checksums for delivery.
 
 ![filegrc audit readiness](docs/filegrc-audit.png)
 
-Starter records connect policies, controls, owners, systems, evidence, and schedules. They are proposals, so review them against how your company actually works before approval.
+The Security starter uses one consolidated Information Security Policy with familiar policy-family headings, one Security Incident and Recovery Plan, one focused Data Retention Schedule, one Security Awareness Training record, and the Controls and Obligations needed for the Security common criteria. The headings make common customer and Vendor questionnaire topics easy to locate, but they do not prove implementation or create separate policy documents. Confirm the applicable Control status and Evidence before answering a questionnaire.
+
+These records are proposals, so review them against how your company actually works. Suggested retention periods and schedule cadences are starting points, not adopted requirements. Add Privacy, Confidentiality, Availability, Processing Integrity, employment, anti-bribery, or other broader GRC material only when the company chooses to expand the scope.
 
 ## Built for engineers and agents
 
@@ -90,6 +96,8 @@ filegrc manages GRC records and audit evidence. Your workforce, identity, source
 
 The independent CPA firm still selects samples, tests controls, evaluates exceptions, decides whether evidence is sufficient, and issues the SOC 2 report.
 
-Do not put secrets or personal data that may need erasure into Git. The editable local server has no authentication and binds to loopback by default.
+For a SOC 2 engagement, scope all 33 Security Common Criteria, all nine Description Criteria, and any optional Trust Services Categories included in the report. The Security Common Criteria remain mandatory. Record any criterion from an optional category judged not relevant under DC8 instead of omitting a Description Criterion.
+
+Do not put plaintext credentials, private keys, tokens, recovery codes, or personal data that may need erasure into Git. Source-controlled ciphertext is allowed only under the Information Security Policy's approved encryption, separate-key, access, and rotation conditions. The editable local server has no authentication and binds to loopback by default.
 
 Learn more at [filegrc.com](https://filegrc.com) or [view the source on GitHub](https://github.com/Alignbase/filegrc).

package/template/WORKSPACE.md

@@ -42,4 +42,6 @@ The editable browser uses `main` and pushes saved changes to `origin`. Connect t
 
 {{starter_setup}}
 
+Do not put plaintext credentials, private keys, authentication tokens, recovery codes, session material, or personal data that may need erasure into Git. Source-controlled ciphertext is allowed only under the Information Security Policy's approved encryption, separate-key, access, and rotation rules.
+
 filegrc manages GRC records and audit evidence. It does not replace infrastructure logging, monitoring, identity, backup, endpoint, or incident-detection systems.

package/template/data/AGENTS.md

@@ -116,6 +116,8 @@ Status is an assertion. Before moving a record to a completed, approved, impleme
 
 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.
 
+Policy approval accepts the reviewed requirements. It does not prove implementation or start governed work. A Control may be implemented while its governing Policy is approved but inactive. Enable its schedules during implementation. At the end of Step 3, run `activate-policies --scaffold`, review the approved Policies together, select the cutover set, and record the real effective date. FileGRC does not infer technical implementation from Policy prose, so put configuration facts in Controls, Components, Systems, governed schedules, and Evidence.
+
 ## Delete and replace
 
 Before deletion:
@@ -169,14 +171,15 @@ Finish each applicable Control and its authoritative source Components together.
 npx filegrc program-readiness --json
 ```
 
-The Control stage reports both Control implementation items and evidence-family source checks. Resolve them through the source records:
+The Control stage reports Control implementation items, evidence-family source checks, governed-plan blockers, and per-Policy activation assessments. Resolve them through the source records:
 
-1. Choose an existing System or scaffold the System that is authoritative for the family.
-2. Set the System to `active`, add the matching `evidenceSourceKinds`, and name current `evidenceOwnerIds`.
-3. Put the exact report, filters, date range, timezone, export format, and reconciliation steps in the System’s Record Markdown.
+1. Choose an existing Component or scaffold the Component that is authoritative for the family.
+2. Set the Component to `active`, connect it to each bounded System through `systemUses` with the `evidence-source` role and a rationale, add the matching `evidenceSourceKinds`, and name current `evidenceOwnerIds`.
+3. Put the exact report, filters, date range, timezone, export format, and reconciliation steps in the Component’s Record Markdown.
 4. Add the Component ID to `evidenceSourceComponentIds` on every Control in the family that it supports.
 5. Finish the Control’s owner, procedure, scope, operation pattern, mappings, and implementation date. Put every calendar or event schedule in an Obligation.
-6. Run `program-readiness --json` again and resolve every failed Control or source check before marking the Controls implemented or starting the candidate period.
+6. Enable each required Obligation. It stays dormant while a governing Policy is inactive.
+7. Run `program-readiness --json`, then use `activate-policies --scaffold` to review and atomically activate the selected approved Policies at implementation cutover. A documented gap or approved Exception may support activation, but the candidate period cannot start until Policies are active and Controls are fully implemented and evidence-ready.
 
 Use `get RESOURCE_ID --mutation` and `update` so JSON and Markdown change together. `evidence-map --json` remains available when you want only the evidence-family checks. Do not create an Evidence Artifact while designing or implementing a Control. Create one during Step 4 only when the real export, report, screenshot, signed file, or approved external reference exists.
 
@@ -203,7 +206,9 @@ npx filegrc audit-readiness AUDIT_ID --json
 npx filegrc evidence-packet --audit AUDIT_ID --preview --json
 ```
 
-Run Program Readiness before creating the normal audit engagement. It checks scope, effective policies, implemented controls, and evidence mapping without an audit ID. Fix readiness errors in the Control and System 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.
+Run Program Readiness before creating the normal audit engagement. Step 2 checks independent Policy approval without requiring activation. Evidence Readiness separately checks active Policies, implemented Controls, enabled schedules, and evidence mapping without an audit ID. Fix readiness errors in Policy, Control, Component, System, governed schedule, and Evidence 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.
+
+For a real engagement, select the Program and its bounded Systems, a framework containing the complete CC1.1 through CC9.2 Security Common Criteria set, all nine SOC 2 Description Criteria, any optional Trust Services Categories in scope, and Controls that cover every applicable selected Trust Services criterion. Treat every Security Common Criterion as applicable. For an included optional category, keep a criterion in the framework when management judges it not relevant and record the limited circumstances in the System Description's DC8 disclosure. Do not omit any of the nine Description Criteria. Use `coverage.kind: "as-of"` with `on` for Type 1 or `coverage.kind: "range"` with `startsOn` and `endsOn` for Type 2. Record the Git commit for management's complete scope review in `scopeRevision`. Record `subserviceConclusion` and its rationale. When subservice organizations are identified, each `subserviceTreatments` item must connect one Vendor to its supplied Components within a selected System and choose the carve-out or inclusive method. Inclusive treatments also need the selected Controls that operate on those Components.
 
 ## Finish every change
 
@@ -214,6 +219,6 @@ 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.
+Review every changed JSON, Markdown, and attachment. Confirm the diff contains no plaintext credentials, private keys, tokens, recovery codes, improperly controlled ciphertext, temporary files, source exports with prohibited data, or derived `.filegrc/` output. Make one focused commit whose message says why the compliance record changed.
 
 These commands are for CLI and agent work, which continues to manage Git explicitly. Browser saves in trunk mode commit automatically from the configured authoritative branch, then push in the background while the UI reports `Syncing`. Do not start another write until it reports `Synced`. Do not use a feature branch as a record approval state, and never include application changes when this workspace lives in a monorepo.

package/template/data/appointments/appointment-policy-owner.json

@@ -7,5 +7,5 @@
   "holderId": "person-program-lead",
   "scopeResourceIds": ["workspace"],
   "startsOn": "{{effective_date}}",
-  "responsibilities": "Own the information security program and the starter policies, controls, documents, training, and scheduled work until management assigns more specific accountable parties."
+  "responsibilities": "Own the information security program, its Policy, Controls, governed documents, training, and scheduled work until management assigns more specific accountable parties."
 }

package/template/data/audits/AGENTS.md

@@ -15,6 +15,10 @@ 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.
 
+Before fieldwork, link the accepted engagement terms as an active approved Document with `documentKind: "soc2-engagement-terms"`. Record the actual acknowledgement date, on or after approval and no later than fieldwork start, and the current management people who acknowledged the terms.
+
+Select a framework containing every CC1.1 through CC9.2 Security Common Criterion, all nine SOC 2 Description Criteria, and any optional Trust Services Categories included in the report. Treat every Security Common Criterion as applicable. For an included optional category, keep a criterion in the framework when management judges it not relevant, record the limited circumstances, and disclose them under DC8. Do not omit any Description Criterion. Bind management's complete scope review to its Git commit in `scopeRevision`. The selected auditor Vendor must represent the CPA firm engaged for the examination and must have been active during the engagement period.
+
 Review both evidence paths for the exact formal date or period:
 
 1. filegrc Evidence consists of dated Step 4 operating records. Complete the record, link it to the applicable Controls, record the result in its fields or Markdown, and link any external artifact needed to support that result.
@@ -30,3 +34,9 @@ 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.
+
+The signed representation requires verified `signed-record` Evidence with `artifactSubtype: "signed-management-representation"` and a fixed-format attachment. Record the letter's actual signing timestamp in `businessEventAt`; `collectedOn` only records when FileGRC received it. The signing date must match the CPA report date once `reportDate` is known. Store the issued SOC 2 report as verified `third-party-report` Evidence with `artifactSubtype: "soc2-report"`, record its actual issuance timestamp in `sourceGeneratedAt`, and link it through `reportEvidenceId` before closing the Audit. Reconcile `reportDate` and `opinionDate` to the date on that issued report.
+
+At report draft and again before closure, record the subsequent-events review through the CPA report date. Name the actual reviewers, review on or after the through date, state management's conclusion, and link relevant incidents, findings, and Evidence.
+
+For each packet delivery, name the people who performed the least-disclosure review and approved delivery. Record the redaction decision, recipient, approved delivery System, exact packet Git revision, SHA-256 manifest checksum, chronological review, approval, and delivery dates, and the receipt reference. Final assertion and representation signers must have active authority Appointments linked from the Audit.

package/template/data/documents/AGENTS.md

@@ -0,0 +1,11 @@
+# Governed Document Instructions
+
+The companion Markdown in this collection is the governed document that management reviews, approves, signs, or gives to the service auditor. Write it as a standalone company artifact.
+
+Do not put FileGRC commands, record-entry instructions, readiness states, relationship IDs, or starter-library mechanics in the governed prose. Keep those details in this guide, the record editor, and calculated work guidance. A document may name FileGRC only when FileGRC itself is part of the document's subject, such as an actual system component or evidence source.
+
+Bracketed prompts mark facts management must supply. Replace every prompt with a reviewed fact before approval, activation, signature, or delivery. FileGRC treats unresolved prompts as content blockers where the document lifecycle requires complete content.
+
+Keep resource links in the Document JSON and supporting records. In the Markdown, describe the underlying business fact in ordinary terms. For example, use “management's control matrix,” “authoritative-source export,” or “signed letter reference” instead of a FileGRC record type or ID.
+
+The SOC 2 assertion, representation letter, period-completeness statement, and system description are management deliverables. Reconcile them to the selected Audit, criteria, Controls, populations, events, and Evidence, but do not describe the repository workflow in the final artifact. The service auditor supplies or approves final engagement wording where applicable.

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

@@ -19,5 +19,5 @@
   ],
   "classificationId": "internal",
   "proposedEffectiveOn": "{{effective_date}}",
-  "programRole": "conditional"
+  "programRole": "required"
 }

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

@@ -10,19 +10,17 @@ 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 | 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 |
+| 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] |
+| 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 |
 
-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.
+Add rows for each important data class in the System and Vendor inventories. A row is incomplete until it names the source System or Component, owner, trigger, period, disposal action, and authority. Remove each bracketed prompt only after replacing it with a reviewed fact.
 
 ## 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.
+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 in controlled legal-hold records.
 
 Any retention exception needs a reason, owner, approval, compensating safeguards, and expiration or next review date.
 

package/template/data/documents/{document-incident-response-plan.json → document-security-incident-recovery-plan.json}

@@ -1,7 +1,7 @@
 {
-  "id": "document-incident-response-plan",
+  "id": "document-security-incident-recovery-plan",
   "type": "document",
-  "title": "Incident Response Plan",
+  "title": "Security Incident and Recovery Plan",
   "status": "draft",
   "documentKind": "plan",
   "ownerIds": [
@@ -17,10 +17,9 @@
     "control-security-communication",
     "control-logging-monitoring",
     "control-incident-response",
-    "control-incident-exercise"
-  ],
-  "relatedDocumentIds": [
-    "document-business-continuity-disaster-recovery"
+    "control-incident-exercise",
+    "control-backup-restoration",
+    "control-continuity-exercise"
   ],
   "evidenceIds": [],
   "classificationId": "internal",

package/template/data/documents/document-security-incident-recovery-plan.md

@@ -0,0 +1,79 @@
+# Security Incident and Recovery Plan
+
+## Purpose
+
+This plan coordinates reporting, response, recovery, and continuity when a security event or disruption affects {{company_name}} or an in-scope service. Supporting procedures, system records, and retained evidence document the actual technical configuration and operation.
+
+## Reporting routes
+
+The primary reporting route is {{security_contact_email}}.
+
+[Complete before activation: Name a usable alternate reporting route, its owner, protected location, and how workers can find it when the primary email, identity, or collaboration System is unavailable, compromised, or involved in the concern. Do not put plaintext credentials, private keys, tokens, or recovery codes in this plan.]
+
+Reports may describe suspected unauthorized access, malware, data loss, credential exposure, security-Control failure, service disruption, fraud affecting the service, or another policy violation. The recipient records the report, protects confidentiality, preserves relevant information, and assigns an initial owner.
+
+## Roles and authority
+
+The Policy Owner maintains this plan and ensures that the organization assigns these duties before activation:
+
+- Incident lead with authority to declare, coordinate, escalate, and close an incident
+- Technical recovery lead for containment, restoration, validation, and rollback
+- System owners for impact assessment, dependencies, and recovery priorities
+- Executive decision-maker for major business, customer, insurance, or legal decisions
+- Communication owner for workforce, customer, Vendor, and public messages
+
+If an incident raises a legal, privacy, or insurance question, the incident lead obtains suitable advice at that time. A pre-arranged counsel relationship or standing legal retainer is required only when management determines that the organization's obligations and risk warrant one.
+
+[Complete before activation: Record the emergency contact arrangement, its owner, alternate communication channel, protected storage location, and review schedule.]
+
+## Assessment and declaration
+
+The incident lead records the affected service, Systems, Components, data, customers, Vendors, known timeline, current impact, likely impact, and available Evidence. Severity and declaration use the approved criteria in the Incident Response Control.
+
+A material incident includes one that causes or is likely to cause significant failure of a service commitment or System requirement, material unauthorized access or disclosure, sustained loss of an important service, or a notification duty requiring leadership review.
+
+## Response
+
+The incident team:
+
+1. Records and assesses the report.
+2. Contains the event while preserving Evidence.
+3. Removes or isolates the cause.
+4. Restores affected service through approved recovery procedures.
+5. Validates security and service behavior before normal operation resumes.
+6. Coordinates any legal, contractual, privacy, insurance, customer, or regulatory review the incident actually requires.
+7. Communicates through authorized primary or alternate channels.
+8. Records decisions, Exceptions, remaining risk, lessons, and follow-up work.
+
+The team does not destroy Evidence, promise external notification, or make public statements without the assigned authority. The notification decision records the triggering law, contract, Policy, commitment, or management decision and the facts used.
+
+## 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.]
+
+Supporting recovery documentation for each important System must identify:
+
+- The backup or alternate recovery approach
+- Scope, frequency, retention, monitoring, and failure response
+- Recovery and restoration procedure
+- People who can access the procedure and required Systems
+- Restore-validation method and approved schedule
+- Dependencies, fallback paths, and validation steps
+
+[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.]
+
+If no approved objective or procedure exists during an event, the incident lead records an interim decision based on customer impact, data risk, and dependencies, then assigns the missing permanent decision as follow-up work.
+
+## Alternate plan access
+
+[Complete before activation: Record the protected alternate location and access method responders will use when the primary identity, source-control, or collaboration Systems are unavailable. Confirm that authorized responders can retrieve the plan without exposing plaintext secrets or decryption keys.]
+
+## Closure and follow-up
+
+The incident lead closes the incident only after affected Systems are stable, security validation is complete, Evidence is preserved, required communication decisions are recorded, and remaining work has owners and deadlines. Material incidents receive a retrospective within the approved event window.
+
+## Exercises and maintenance
+
+Management tests a representative security alert from generation through receipt, acknowledgement, escalation, and fallback on the approved schedule. It also exercises incident coordination, alternate plan access, emergency contacts, and recovery of selected important Systems on their approved schedules.
+
+Each exercise records scope, participants, objectives, result, Evidence, Exceptions, findings, and follow-up. The owner reviews this plan after a material incident, failed exercise, important System change, or reporting-path change and on the approved Policy-review schedule.

package/template/data/documents/document-soc2-management-assertion.md

@@ -1,24 +1,24 @@
 # {{company_name}} Management Assertion
 
-> Draft preparation document. Reconcile this draft to the wording agreed with the service auditor before approval.
+> Draft preparation document. Retain the section that matches the engagement, remove the other draft section, and reconcile the final wording with the service auditor before approval.
+
+## Type 1 Assertion Draft
 
-<!-- type-1:start -->
 Management is responsible for the attached description of the in-scope system as of [as-of date] and for designing, implementing, and documenting the controls within that system.
 
 Based on the criteria selected for the engagement, management asserts that:
 
-1. The description presents the system that was designed and implemented as of [as-of date].
+1. The attached description presents the system as designed and implemented as of [as-of date], in accordance with the applicable SOC 2 Description Criteria.
 2. The controls stated in the description were suitably designed to provide reasonable assurance that the applicable service commitments, system requirements, and Trust Services Criteria would be met, assuming the complementary controls identified in the description operated effectively.
-<!-- type-1:end -->
 
-<!-- type-2:start -->
+## Type 2 Assertion Draft
+
 Management is responsible for the attached description of the in-scope system for [start date] through [end date] and for designing, implementing, operating, and documenting the controls within that system.
 
 Based on the criteria selected for the engagement, management asserts that:
 
-1. The description presents the system that was designed and implemented during [start date] through [end date].
+1. The attached description presents the system as designed and implemented during [start date] through [end date], in accordance with the applicable SOC 2 Description Criteria.
 2. The controls stated in the description were suitably designed to provide reasonable assurance that the applicable service commitments, system requirements, and Trust Services Criteria would be met, assuming the complementary controls identified in the description operated effectively.
 3. The controls operated effectively throughout [start date] through [end date].
-<!-- type-2:end -->
 
 [Identify the responsible management signer, title, signature or approval method, and date.]

package/template/data/documents/document-soc2-management-representation.md

@@ -17,4 +17,4 @@ Final letter received from auditor: [Date]
 
 Management signer and title: [Name and title]
 
-Signed letter evidence record: [Evidence ID]
+Signed letter reference: [Approved storage location or evidence reference]

package/template/data/documents/document-soc2-period-completeness.md

@@ -4,9 +4,9 @@
 
 Reporting period: [start date] through [end date]
 
-Management reconciled every audit-population record linked to this engagement to its authoritative source and included every item relevant to the in-scope system and controls. The generated `population-index.csv` is incorporated into this statement by reference and records each population ID, source system, query, timezone, count, validation, reviewer, conclusion, and fixed export.
+Management reconciled every population used for this engagement to its authoritative source and included every item relevant to the in-scope system and controls. The accompanying `population-index.csv` is incorporated into this statement by reference and records each population reference, source system, query, timezone, count, validation, reviewer, conclusion, and fixed export.
 
-| Population | filegrc population ID | Result or exception |
+| Population | Population reference | Result or exception |
 | --- | --- | --- |
 | Workforce starts, role changes, and departures | [Population ID] | [Result] |
 | Access grants, changes, reviews, and removals | [Population ID] | [Result] |
@@ -19,7 +19,7 @@ Management reconciled every audit-population record linked to this engagement to
 | Backup failures and restoration tests | [Population ID] | [Result] |
 | Security exceptions and control findings | [Population ID] | [Result] |
 
-For a population with zero items, retain the source-Component export or report that produced the zero count. Describe any source limitation, omitted item, or reconciliation difference below.
+For a population with zero items, retain the authoritative-source export or report that produced the zero count. Describe any source limitation, omitted item, or reconciliation difference below.
 
 ## Exceptions and Source Limitations
 
@@ -27,6 +27,6 @@ For a population with zero items, retain the source-Component export or report t
 
 ## Management Confirmation
 
-To the best of management's knowledge after the reconciliations above, filegrc and the linked evidence contain the complete populations and reportable events relevant to the engagement period.
+To the best of management's knowledge after the reconciliations above, management's records and linked evidence contain the complete populations and reportable events relevant to the engagement period.
 
 [Identify the responsible signer, title, signature or approval method, and date.]

package/template/data/documents/document-soc2-system-description.md

@@ -1,6 +1,6 @@
 # {{company_name}} SOC 2 System Description
 
-> Draft preparation document. Complete every bracketed item, reconcile it to the filegrc records, and have the service auditor review the final presentation.
+> Draft preparation document. Complete every bracketed item, reconcile it to management's authoritative records, and have the service auditor review the final presentation.
 
 ## Reporting Period and Scope
 
@@ -16,7 +16,7 @@
 
 ## DC2: Service Commitments and System Requirements
 
-[Summarize customer commitments, contractual security promises, internal objectives, and the system requirements needed to meet them. Link the filegrc commitment records.]
+[Summarize customer commitments, contractual security promises, internal objectives, and the system requirements needed to meet them. Reconcile the summary to supporting commitment records.]
 
 ## DC3: System Components
 
@@ -46,7 +46,7 @@
 
 ## DC5: Applicable Criteria and Controls
 
-[Reference the selected criteria and control matrix generated by filegrc.]
+[Reference the selected criteria and management's control matrix.]
 
 ## DC6: Complementary User Entity Controls
 
@@ -58,7 +58,7 @@
 
 ## DC8: Criteria Not Relevant
 
-[Identify any criteria within an included category that are not relevant and explain why.]
+[State that CC1.1 through CC9.2 remain in scope for the mandatory Security category. For any optional Trust Services Category, identify a criterion that the service auditor agrees is not relevant in the limited circumstances allowed by the criteria, and explain why. Otherwise state that management identified no criteria as not relevant.]
 
 ## DC9: Significant Changes
 

package/template/data/evidence/AGENTS.md

@@ -29,4 +29,4 @@ For a signed acknowledgement, bind the attestation to the exact content Git revi
 
 For a `population-export`, also record the authoritative `sourceComponentId`, exact period, generation timestamp, timezone, query or report parameters, item count, completeness check, and accuracy check. A zero-item population still needs its source export and query.
 
-Do not commit secrets, session data, regulated data, or personal data that may need erasure. Use an approved external reference when Git is not an appropriate store.
+Do not commit plaintext credentials, private keys, tokens, recovery codes, session data, regulated data, or personal data that may need erasure. Source-controlled ciphertext is allowed only under the Information Security Policy's approved encryption, separate-key, access, and rotation conditions. Use an approved external reference when Git is not an appropriate store.

package/template/data/obligations/AGENTS.md

@@ -5,7 +5,8 @@ An obligation is a reusable policy schedule or event template. It is not the rec
 - Calendar obligations need a valid recurrence anchor, owners, expected completion types, and policy or control links.
 - Event obligations need a stable lowercase `eventType`, a prompt, owners, expected completion types, and an explicit deadline window.
 - Keep completed occurrences in `completionResourceIds`. Do not replace prior links when a new period starts.
-- Keep starter obligations as proposals until every governing policy is active and effective and, when the obligation names controls, at least one linked control is implemented.
+- Configure and enable Obligations during Step 3. An enabled Obligation remains dormant until every governing Policy is active and effective and, when it names Controls, at least one linked Control is implemented.
+- Calendar Obligations generated with `status: proposed` contain suggested starting cadences. Review the scope and risk, edit the cadence when needed, and change the Obligation to `active` only when management accepts that schedule. A proposed Obligation never counts as a configured schedule.
 - When an approved cadence changes, update the policy, control, and obligation together.
 - Pause or retire a template only when the underlying policy work no longer applies. Do not delete historical templates that explain prior periods.