create-filegrc 0.7.0 → 0.7.1

package/README.md

@@ -28,7 +28,7 @@ For one noninteractive run, pass company and service fields together or use `--c
     "serviceName": "Example Service",
     "boundary": "The production service and supporting infrastructure.",
     "criticality": "high",
-    "dataClassification": "Confidential",
+    "classificationId": "confidential",
     "internetExposed": true,
     "programGoal": "type-2"
   }

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "create-filegrc",
-  "version": "0.7.0",
+  "version": "0.7.1",
   "description": "Create a filegrc workspace for a SOC 2 program",
   "license": "MIT",
   "repository": {

package/src/defaults.js

@@ -88,7 +88,7 @@ const descriptionCriteria = [
   ["DC5", "Applicable criteria and controls", "Identify the applicable trust services criteria and the controls designed to address them."],
   ["DC6", "Complementary user entity controls", "Describe controls that customers are expected to operate for the service organization's controls to work as intended."],
   ["DC7", "Subservice organizations and controls", "Describe relevant subservice organizations, how their controls are treated, and complementary controls they are expected to operate."],
-  ["DC8", "Criteria not relevant", "Identify any trust services criteria within an included category that are not relevant to the system and explain why."],
+  ["DC8", "Criteria not relevant", "Confirm that every Security Common Criterion applies. Identify any criterion from an included optional Trust Services Category that is not relevant to the system and explain the limited circumstances."],
   ["DC9", "Significant changes", "Describe significant system changes during the reporting period that could affect a report user's understanding of the system."]
 ];
 const commonCriteriaReferences = commonCriteria.map(([reference]) => reference);
@@ -109,10 +109,10 @@ const controls = [
   {
     id: "control-policy-management",
     code: "GOV-02",
-    title: "Policy management",
-    statement: "The policy owner reviews governed policies and plans at least annually and after material changes, obtains approval from a separate independent approver, and retains the approved revisions in Git.",
+    title: "Control and policy management",
+    statement: "Management selects and develops manual and technology Controls from approved objectives, commitments, risks, dependencies, and changes, and records each Control's owner, scope, procedure, operation pattern, evidence source, and implementation status. The policy owner reviews Controls, governed policies, and plans at least annually and after material changes, obtains separate approval for governed content, and retains approved revisions in Git.",
     requirements: ["CC5.1", "CC5.2", "CC5.3"],
-    activity: "Review, approve, communicate, and version policies and plans.",
+    activity: "Review Control design and evidence paths, correct gaps or approve time-bound Exceptions, and review, approve, communicate, and version governed policies and plans.",
     controlType: "preventive",
     operationMode: "manual",
     operationPattern: "mixed",
@@ -121,10 +121,10 @@ const controls = [
   {
     id: "control-security-communication",
     code: "GOV-03",
-    title: "Security communication",
-    statement: "The organization communicates security responsibilities, approved reporting routes, material changes, and relevant control information to its workforce and outside parties.",
+    title: "Security information and communication",
+    statement: "Management obtains or generates, checks, and uses relevant and reliable information from internal and external sources to operate Controls, and communicates security responsibilities, approved reporting routes, material changes, and relevant Control information to its workforce and outside parties in time for action.",
     requirements: ["CC2.1", "CC2.2", "CC2.3"],
-    activity: "Maintain reporting routes and communicate policies, changes, and security information.",
+    activity: "Record material information sources, scope, period, ownership, and known limits; maintain reporting routes; and communicate policies, changes, and security information.",
     controlType: "preventive",
     operationMode: "hybrid",
     operationPattern: "mixed",
@@ -134,12 +134,12 @@ const controls = [
     id: "control-workforce-expectations",
     code: "HR-01",
     title: "Workforce expectations",
-    statement: "Workers agree to applicable conduct, confidentiality, acceptable-use, and security responsibilities before receiving access and are held accountable for violations.",
-    requirements: ["CC1.4"],
-    activity: "Complete screening when appropriate, agreements, policy acknowledgement, and corrective action.",
+    statement: "Workers are screened before sensitive access when lawful and appropriate to role risk, have the competence needed for assigned duties, agree to applicable conduct, confidentiality, acceptable-use, intellectual-property, and security responsibilities before receiving access, and are held accountable for violations.",
+    requirements: ["CC1.4", "CC1.5"],
+    activity: "Record the role-based screening decision, confirm competence and authority, complete agreements and policy acknowledgement, and take corrective action when needed.",
     controlType: "preventive",
     operationMode: "manual",
-    operationPattern: "event-driven",
+    operationPattern: "mixed",
     policies: [INFORMATION_SECURITY_POLICY_ID]
   },
   {
@@ -158,9 +158,9 @@ const controls = [
     id: "control-risk-assessment",
     code: "RSK-01",
     title: "Risk assessment and treatment",
-    statement: "The organization assesses information security risk at least annually and after material changes, assigns owners and responses, and reviews high and critical risks at least quarterly.",
+    statement: "The organization defines security objectives and risk tolerance, assesses information security, fraud, misconduct, dependency, and change risk at least annually and after material changes, assigns owners and responses, and reviews high and critical risks at least quarterly.",
     requirements: ["CC3.1", "CC3.2", "CC3.3", "CC3.4", "CC9.1"],
-    activity: "Identify threats and changes, score risk, select treatment, and track review dates.",
+    activity: "Confirm objectives and risk tolerance, identify internal and external threats, fraud and misconduct scenarios, dependencies, and changes, score risk, select treatment, and track review dates.",
     controlType: "detective",
     operationMode: "manual",
     operationPattern: "mixed",
@@ -170,7 +170,7 @@ const controls = [
     id: "control-monitoring-remediation",
     code: "MON-01",
     title: "Control monitoring and remediation",
-    statement: "Management reviews control operation, incidents, test results, exceptions, and findings, then assigns and tracks corrective work through completion.",
+    statement: "Management reviews Control operation, source information, incidents, test results, Exceptions, and findings at least quarterly and after significant failures, then communicates deficiencies and assigns, tracks, and verifies corrective work through completion.",
     requirements: ["CC4.1", "CC4.2"],
     activity: "Review control evidence and track deficiencies, owners, due dates, and verification.",
     controlType: "detective",
@@ -194,9 +194,9 @@ const controls = [
     id: "control-strong-authentication",
     code: "IAM-02",
     title: "Strong authentication",
-    statement: "Important systems use approved authentication settings, protected unique credentials, and multi-factor authentication for administrative, production, source-control, email, identity, and sensitive-data access when supported.",
+    statement: "Important Systems use approved strong-authentication settings, unique identities, protected credentials, changed or disabled default credentials, and separate administrative identities or roles when technically supported and appropriate to risk. Multi-factor authentication is required for workforce and administrative access to production, source control, email, identity, and Systems that provide access to Confidential or Restricted data. Customer and external-user authentication requirements follow approved Controls, customer commitments, and risk decisions. Where required MFA is unavailable, management approves a time-bound Exception with a risk assessment, compensating Controls, an accountable owner, and a review or expiration date.",
     requirements: ["CC6.1", "CC6.2", "CC6.6"],
-    activity: "Configure and monitor authentication, credential storage, and privileged roles.",
+    activity: "Configure and monitor authentication, credential and recovery-material protection, default credentials, privileged identities or roles, customer requirements, and approved MFA Exceptions.",
     controlType: "preventive",
     operationMode: "hybrid",
     operationPattern: "continuous",
@@ -242,9 +242,9 @@ const controls = [
     id: "control-encryption-transmission",
     code: "DATA-02",
     title: "Encryption and secure transmission",
-    statement: "Confidential and Restricted data is encrypted in transit over untrusted networks and at rest in approved systems and on devices, with protected key access.",
+    statement: "Confidential and Restricted data is encrypted in transit over untrusted networks and at rest in approved Systems and on devices, with named key ownership, protected key access, and risk-based key lifecycle controls.",
     requirements: ["CC6.1", "CC6.7"],
-    activity: "Configure encryption and approved transfer methods based on classification.",
+    activity: "Configure encryption and approved transfer methods based on classification, and control key generation, storage, distribution, rotation, revocation, and recovery as applicable.",
     controlType: "preventive",
     operationMode: "automated",
     operationPattern: "continuous",
@@ -259,16 +259,16 @@ const controls = [
     activity: "Apply approved retention and disposal methods to active, local, backup, and vendor-held copies.",
     controlType: "preventive",
     operationMode: "hybrid",
-    operationPattern: "event-driven",
+    operationPattern: "mixed",
     policies: [INFORMATION_SECURITY_POLICY_ID]
   },
   {
     id: "control-inventory-configuration",
     code: "OPS-01",
     title: "System inventory and secure configuration",
-    statement: "The organization maintains inventories of important systems, company and approved personal devices, service accounts, vendors, and data stores, with owners, lifecycle state, and secure configuration expectations.",
+    statement: "The organization maintains inventories of important Systems, Components, company and approved personal devices, software, service accounts, Vendors, and data stores, with owners, lifecycle state, and secure configuration expectations. Unsupported or unneeded important assets are upgraded, isolated, replaced, or retired according to risk.",
     requirements: ["CC6.1", "CC7.1"],
-    activity: "Maintain inventories, baselines, ownership, classification, and approved deviations.",
+    activity: "Maintain inventories, baselines, ownership, classification, lifecycle decisions, secure retirement, and approved deviations.",
     controlType: "preventive",
     operationMode: "hybrid",
     operationPattern: "mixed",
@@ -279,8 +279,8 @@ const controls = [
     code: "OPS-02",
     title: "Endpoint protection",
     statement: "Devices that access company systems use approved configuration, encryption, screen locking, supported software, security updates, and continuous malware protection when supported.",
-    requirements: ["CC6.6", "CC7.1"],
-    activity: "Use continuous platform protection where supported and verify endpoint configuration, update, and compliance state on the risk-based schedule recorded in an Obligation when periodic work is needed.",
+    requirements: ["CC6.6", "CC6.8", "CC7.1"],
+    activity: "Use continuous platform protection where supported and verify endpoint configuration, update, and compliance state on the approved risk-based schedule when periodic work is needed.",
     controlType: "preventive",
     operationMode: "automated",
     operationPattern: "mixed",
@@ -290,9 +290,9 @@ const controls = [
     id: "control-network-security",
     code: "NET-01",
     title: "Network and remote-access security",
-    statement: "The organization restricts network paths, protects remote access with approved encryption and authentication, and reviews material network access rules at least annually.",
+    statement: "The organization restricts network paths, separates production and nonproduction environments according to data and risk, protects remote access with approved encryption and authentication, and reviews material network access rules at least annually.",
     requirements: ["CC6.6", "CC6.7"],
-    activity: "Manage boundaries, firewall rules, wireless safeguards, and remote production access.",
+    activity: "Manage boundaries, environment connections, firewall rules, wireless safeguards, and remote production access.",
     controlType: "preventive",
     operationMode: "hybrid",
     operationPattern: "mixed",
@@ -302,12 +302,12 @@ const controls = [
     id: "control-change-management",
     code: "CHG-01",
     title: "Change management",
-    statement: "Material software and infrastructure changes are recorded, tested, approved, deployed through an authorized process, and recoverable. Review is independent when practical; a small team records a risk-appropriate compensating or post-deployment review, or an approved Exception, when independent pre-deployment review is not possible.",
+    statement: "Source and deployment paths protect against unauthorized changes and malicious software. Material software and infrastructure changes are recorded, receive a security design or threat analysis suited to their risk, are tested, approved, deployed through an authorized process, and are recoverable. Review is independent when practical; a small team records a risk-appropriate compensating or post-deployment review, or an approved Exception, when independent pre-deployment review is not possible.",
     requirements: ["CC6.8", "CC8.1"],
-    activity: "Record the reason, author, risk, reviewer or compensating review, test result, deployment, and rollback method.",
+    activity: "Record the reason, author, risk, security analysis when applicable, reviewer or compensating review, test result, deployment, communication, and rollback method.",
     controlType: "preventive",
     operationMode: "hybrid",
-    operationPattern: "event-driven",
+    operationPattern: "mixed",
     policies: [INFORMATION_SECURITY_POLICY_ID]
   },
   {
@@ -316,7 +316,7 @@ const controls = [
     title: "Vulnerability management",
     statement: "The organization monitors for vulnerabilities, chooses scan coverage and cadence based on exposure and risk, and assigns each confirmed vulnerability an approved risk-based remediation target or time-bound Exception.",
     requirements: ["CC7.1", "CC7.2", "CC7.3"],
-    activity: "Choose scan coverage and cadence. Review the starter remediation targets of Critical 7 days, High 14 days, Medium 30 days, and Low 90 days, then record the approved targets or time-bound Exceptions.",
+    activity: "Choose scan coverage and cadence, define approved risk-based remediation targets, and document time-bound Exceptions when a target cannot be met.",
     controlType: "detective",
     operationMode: "hybrid",
     operationPattern: "mixed",
@@ -328,7 +328,7 @@ const controls = [
     title: "Penetration testing",
     statement: "Management records whether independent penetration testing is needed for the in-scope service, then documents its scope and cadence from exposure, change, customer commitments, and risk decisions. Findings are tracked to resolution or approved risk treatment.",
     requirements: ["CC7.1", "CC7.2"],
-    activity: "Define scope, perform independent testing, review results, and track findings.",
+    activity: "Review and record applicability and cadence. When testing is required, define its scope and independence, perform the test, review results, and track findings.",
     controlType: "detective",
     operationMode: "manual",
     operationPattern: "scheduled",
@@ -338,9 +338,9 @@ const controls = [
     id: "control-logging-monitoring",
     code: "LOG-01",
     title: "Logging and monitoring",
-    statement: "Important systems record and protect security and operational events, retain them according to the approved Data Retention Schedule, and use risk-based alerting, review, and alert-path testing recorded in the applicable Controls and Obligations.",
+    statement: "Important Systems record and protect security and operational events, retain them according to the approved Data Retention Schedule, and use risk-based alerting, review, and alert-path testing. Systems with availability commitments, recovery objectives, or material operational dependencies also monitor the health, capacity, failure, and service indicators needed to detect degradation.",
     requirements: ["CC7.2", "CC7.3"],
-    activity: "Collect, protect, alert on, test, and review important log output and access.",
+    activity: "Collect, protect, alert on, test, and review important log output, access, and applicable health, capacity, failure, and service indicators.",
     controlType: "detective",
     operationMode: "hybrid",
     operationPattern: "mixed",
@@ -398,9 +398,9 @@ const controls = [
     id: "control-vendor-due-diligence",
     code: "VEN-01",
     title: "Vendor due diligence and contracting",
-    statement: "New Vendors receive risk-based security and privacy review and suitable contractual safeguards before access to Confidential or Restricted data. Vendors that predate Policy adoption receive a documented transition review, deadline, or approved risk acceptance.",
+    statement: "New Vendors receive risk-based security and privacy review and suitable contractual safeguards before access to Confidential or Restricted data or material reliance by an important service. Applicable contracts address permitted use and confidentiality, security responsibilities, incident notice, access and subprocessor restrictions, continuity, data return or deletion, termination, and assurance rights. Vendors that predate Policy adoption receive a documented transition review, deadline, or approved risk acceptance.",
     requirements: ["CC9.2"],
-    activity: "Assess service, data, access, assurance, recovery, incidents, and contract terms before access.",
+    activity: "Assess service, data, access, assurance, recovery, incidents, dependencies, supplied Components, and applicable contract safeguards before access or material reliance.",
     controlType: "preventive",
     operationMode: "manual",
     operationPattern: "event-driven",
@@ -440,7 +440,11 @@ const obligations = [
     recurrence: calendar("month", 3),
     ownerIds: [OVERSIGHT_TEAM_ID],
     scopeResourceIds: [OVERSIGHT_TEAM_ID],
-    controlIds: ["control-security-governance"],
+    controlIds: [
+      "control-security-governance",
+      "control-security-communication",
+      "control-monitoring-remediation"
+    ],
     policyIds: [INFORMATION_SECURITY_POLICY_ID]
   },
   {
@@ -454,7 +458,16 @@ const obligations = [
       SECURITY_PLAN_ID,
       RETENTION_SCHEDULE_ID
     ],
-    controlIds: ["control-policy-management"],
+    controlIds: ["control-policy-management", "control-data-retention-disposal"],
+    policyIds: [INFORMATION_SECURITY_POLICY_ID]
+  },
+  {
+    id: "obligation-annual-control-design-review",
+    title: "Annual Control design and evidence-path review",
+    activityType: "control-design-review",
+    recurrence: calendar("year", 1),
+    ownerIds: [OVERSIGHT_TEAM_ID],
+    controlIds: ["control-policy-management", "control-monitoring-remediation"],
     policyIds: [INFORMATION_SECURITY_POLICY_ID]
   },
   {
@@ -466,6 +479,15 @@ const obligations = [
     controlIds: ["control-risk-assessment"],
     policyIds: [INFORMATION_SECURITY_POLICY_ID]
   },
+  {
+    id: "obligation-annual-workforce-competence-review",
+    title: "Annual workforce security-role competence review",
+    activityType: "performance-review",
+    recurrence: calendar("year", 1),
+    ownerIds: [POLICY_OWNER_APPOINTMENT_ID],
+    controlIds: ["control-workforce-expectations"],
+    policyIds: [INFORMATION_SECURITY_POLICY_ID]
+  },
   {
     id: "obligation-annual-security-training",
     title: "Annual security awareness training",
@@ -537,8 +559,8 @@ const obligations = [
   },
   {
     id: "obligation-annual-penetration-test",
-    title: "Annual independent penetration test",
-    activityType: "penetration-test",
+    title: "Annual penetration-testing applicability and cadence review",
+    activityType: "risk-assessment",
     recurrence: calendar("year", 1),
     ownerIds: [POLICY_OWNER_APPOINTMENT_ID],
     controlIds: ["control-penetration-testing"],
@@ -603,6 +625,17 @@ const obligations = [
     controlIds: ["control-continuity-exercise"],
     policyIds: [INFORMATION_SECURITY_POLICY_ID]
   },
+  {
+    id: "obligation-worker-start-screening",
+    title: "Record the role-based screening and competence decision before sensitive access",
+    activityType: "workforce-review",
+    recurrence: event("person-started"),
+    triggerPrompt: "New employee or contractor?",
+    window: eventWindow(0),
+    ownerIds: [POLICY_OWNER_APPOINTMENT_ID],
+    controlIds: ["control-workforce-expectations"],
+    policyIds: [INFORMATION_SECURITY_POLICY_ID]
+  },
   {
     id: "obligation-worker-start-agreements",
     title: "Collect workforce agreements and policy acknowledgements",
@@ -694,6 +727,17 @@ const obligations = [
     controlIds: ["control-access-authorization", "control-access-review-offboarding"],
     policyIds: [INFORMATION_SECURITY_POLICY_ID]
   },
+  {
+    id: "obligation-worker-role-change-training",
+    title: "Assign and complete applicable role-based security training",
+    activityType: "role-training",
+    recurrence: event("person-role-changed"),
+    triggerPrompt: "Worker role changed?",
+    window: eventWindow(30),
+    ownerIds: [POLICY_OWNER_APPOINTMENT_ID],
+    controlIds: ["control-workforce-expectations", "control-security-training"],
+    policyIds: [INFORMATION_SECURITY_POLICY_ID]
+  },
   {
     id: "obligation-personal-device-approval",
     title: "Approve personal-device access and security conditions before use",

package/src/index.js

@@ -523,13 +523,13 @@ async function runCombinedSetup(target, input) {
 async function writeMinimalLockfile(target, name, versionRange) {
   const lock = {
     name,
-    version: "0.7.0",
+    version: "0.7.1",
     lockfileVersion: 3,
     requires: true,
     packages: {
       "": {
         name,
-        version: "0.7.0",
+        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
@@ -233,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}}
 
@@ -244,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

@@ -64,7 +64,9 @@ The Program Overview shows what is done, what is blocked, and what to do next.
 
 ![filegrc audit readiness](docs/filegrc-audit.png)
 
-The Security starter is intentionally small: one Information Security Policy, 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. They 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.
+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
 
@@ -94,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

@@ -173,9 +173,9 @@ npx filegrc program-readiness --json
 
 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. Enable each required Obligation. It stays dormant while a governing Policy is inactive.
@@ -208,6 +208,8 @@ npx filegrc evidence-packet --audit AUDIT_ID --preview --json
 
 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
 
 ```sh
@@ -217,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/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.md

@@ -16,11 +16,11 @@ Retention periods may come from law, contract, tax, audit, security, or a docume
 | 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 or Component, owner, trigger, period, disposal action, and authority. FileGRC detects the bracketed prompts as approval blockers. Remove each prompt only after replacing it with a reviewed fact.
+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-security-incident-recovery-plan.md

@@ -2,13 +2,13 @@
 
 ## Purpose
 
-This plan coordinates reporting, response, recovery, and continuity when a security event or disruption affects {{company_name}} or an in-scope service. Controls, Components, Systems, Obligations, and Evidence hold the actual technical configuration and proof of operation.
+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 secrets in this plan.]
+[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.
 
@@ -22,7 +22,7 @@ The Policy Owner maintains this plan and ensures that the organization assigns t
 - 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 gets suitable advice at that time. FileGRC does not require pre-arranged counsel, in-house counsel, or a standing legal retainer.
+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.]
 
@@ -49,24 +49,24 @@ The team does not destroy Evidence, promise external notification, or make publi
 
 ## Recovery priorities and procedures
 
-[Complete before activation: Link every important System and record its approved recovery time objective, recovery point objective, maximum tolerable downtime, dependencies, owner, and critical customer commitments in the System record.]
+[Complete before activation: Document every important System's approved recovery time objective, recovery point objective, maximum tolerable downtime, dependencies, owner, and critical customer commitments.]
 
-For each important System, the applicable Control, Component, System, and Obligation records must identify:
+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 governed schedule
+- Restore-validation method and approved schedule
 - Dependencies, fallback paths, and validation steps
 
-[Confirm or replace before activation: The starter proposal for important production data is a daily backup, 30-day retention period, and annual restore validation. Record the approved choice for every important System in its Control, Component, System, Retention Schedule, and Obligation records.]
+[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 secrets.]
+[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
 
@@ -74,6 +74,6 @@ The incident lead closes the incident only after affected Systems are stable, se
 
 ## Exercises and maintenance
 
-Management tests a representative security alert from generation through receipt, acknowledgement, escalation, and fallback on the approved governed schedule. It also exercises incident coordination, alternate plan access, emergency contacts, and recovery of selected important Systems on their approved schedules.
+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/policies/AGENTS.md

@@ -10,7 +10,9 @@ Use the `content` Markdown slot for the policy text. Keep ownership and approval
 
 Keep a Policy `draft` until its text, owner, scope, related Requirements and Controls, review Obligation, and acknowledgement requirement are ready for independent review. Move it to `approved` when management accepts the exact content revision. Approval does not require every linked Control to be implemented and does not make the Policy effective.
 
-The Security starter contains one Information Security Policy. Add another Policy only when management expands the program scope or has a distinct approval audience, owner, or legal requirement.
+The Security starter contains one consolidated Information Security Policy. Its section headings use common policy-family names so a customer, auditor, or questionnaire reviewer can locate topics such as access control, personnel security, vulnerability management, incident response, continuity, and Vendor risk. Cite the consolidated Policy and exact section when that accurately answers a request. Do not claim that each section is a separate document, that the heading proves implementation, or that FileGRC supplies a certification.
+
+Add another Policy only when management expands the program scope or has a distinct approval audience, owner, or legal requirement.
 
 During Step 3, implement Controls while the governing Policy is approved but inactive. Configure and enable its schedules, which remain dormant. Use the Controls-page cutover or `activate-policies --scaffold` to review the approved Policy. Before selecting it for activation:
 
@@ -25,3 +27,5 @@ The independent Policy approver is a management reviewer, not the CPA auditor. A
 If a proposed effective date has passed, choose a current or future activation date. Never backdate adoption.
 
 For a material revision, preserve Git history, obtain a new approval, and require a new acknowledgement when the audience’s responsibilities changed. Do not reuse the audit firm as a management approver without confirming independence.
+
+After updating the `filegrc` package, run `npx filegrc policy-library` to review optional starter updates. The command prints exact diffs and skips customized or adopted Policy content. It writes only after you accept the named proposal and exact revision with the printed `--accept`, `--proposal-revision`, and `--yes` command. Acceptance fails if the proposal changed after review. It does not approve the Policy or mark a linked Control implemented.

package/template/data/policies/policy-information-security.json

@@ -10,8 +10,7 @@
   "version": "1.0",
   "audience": [
     "employees",
-    "contractors",
-    "vendors"
+    "contractors"
   ],
   "acknowledgementRequired": true,
   "relatedDocumentIds": [

package/template/data/policies/policy-information-security.md

@@ -4,95 +4,287 @@
 
 This Policy defines the information security requirements for {{company_name}} and its in-scope services. It applies to employees, contractors, authorized users, Systems, Components, devices, code, data, facilities, and Vendors used to provide or protect those services. Vendor requirements apply through approved contracts and oversight.
 
-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 this prose. Configuration facts belong in Controls, Components, Systems, governed schedules, and Evidence.
+This consolidated Policy uses security-policy names commonly requested in customer questionnaires and assurance reviews. A questionnaire response may cite this Policy and the applicable section, but it must reflect the organization's actual scope, implemented Controls, approved Exceptions, and available Evidence. A section title does not establish a separate document or prove that a Control operates.
 
-## Integrity, accountability, and reporting
+This Policy establishes management requirements. Approval means the company accepts those requirements, which become effective only on the recorded effective date. Approval does not by itself demonstrate implementation or operation. Management documents supporting procedures, configurations, Control operation, and Evidence separately.
 
-Everyone in scope must act honestly, protect company and customer information, follow approved security processes, disclose conflicts that could affect security decisions, and preserve accurate records. Fraud, deliberate control bypass, false evidence, credential sharing, unauthorized access, concealment of a security event, and retaliation for a good-faith report are prohibited.
+## Consolidated policy index
 
-Suspected security events, control failures, fraud, or policy violations must be reported promptly through the primary route at {{security_contact_email}} or the usable alternate route documented in the Security Incident and Recovery Plan. A person may use the alternate route when the primary route is unavailable, compromised, or involved in the concern. Management investigates credible reports, limits disclosure to people who need the information, preserves relevant records, and records corrective action.
+- **Governance and workforce:** Information Security Governance and Organization; Risk Management and Compliance; Personnel and Human Resources Security; Security Awareness and Training; Acceptable Use, Clear Desk, and Clear Screen.
+- **Assets, data, and access:** Asset Management; Data Classification, Handling, and Protection; Access Control; Identification, Authentication, and Password.
+- **Technology protection:** Cryptography, Encryption, Key, and Secrets Management; Endpoint, Mobile Device, BYOD, and Malware Protection; Remote Access and Remote Work; Physical and Environmental Security; Network and Communications Security; Configuration Management and System Maintenance.
+- **Engineering and security operations:** Secure Development and Change Management; Vulnerability, Patch, and Penetration Testing; Logging, Monitoring, and Audit Trail; Incident Response.
+- **Resilience and third parties:** Business Continuity and Disaster Recovery; Backup and Restoration; Vendor, Third-Party, and Supply Chain Risk Management; Exceptions, Compliance, Enforcement, and Policy Review.
 
-Management evaluates conduct against these requirements and addresses violations consistently. Contractors and Vendor personnel follow equivalent requirements when their work or access can affect the in-scope service.
+## Definitions
 
-## Governance and risk management
+- **Worker:** An employee or contractor.
+- **System:** An application, service, process, or infrastructure used to store or process information or support an in-scope service.
+- **Component:** A technology, process, facility, or provider-supplied element within or supporting a System.
+- **Control:** An administrative, technical, or physical safeguard.
+- **Evidence:** Retained information that supports a security fact, decision, or activity.
+- **Vendor:** An external party that provides a product or service.
+- **Exception:** A management-approved, time-bound departure from a requirement.
+- **Important System or Component:** A System or Component included in the approved service boundary or relied upon to meet a security objective, service commitment, recovery objective, Control, or Evidence need.
+- **Approved:** Authorized by the accountable owner or management under the applicable governance process.
 
-The current Policy Owner maintains this Policy, the risk program, Controls, governed plans, Exceptions, and improvement work. System and process owners approve access, maintain safeguards, keep inventories and recovery facts current, and resolve findings. An independent reviewer who is separate from the Policy owner approves the Policy and challenges management's assessment of Control operation.
+These definitions set the minimum scope. Management may classify additional assets as important based on risk.
 
-Management reviews the security program on its approved governed schedule and after material change. Reviews cover objectives, service commitments, fraud and misconduct risk, threats, system and Vendor changes, incidents, findings, Exceptions, overdue work, and Control results. Risks receive an owner, response, target date, approval when accepted, and a review date. The Risk Assessment Control and Obligations record the actual method and cadence.
+## Information Security Governance and Organization Policy
 
-## Workforce security and acceptable use
+### Roles and oversight
 
-Workers must accept applicable confidentiality, acceptable-use, and security responsibilities before receiving access. They receive security training on the approved onboarding and recurring schedules. Role-specific instruction is assigned when a person's access or duties require it.
+- **Policy Owner:** Maintains this Policy, the risk program, Controls, approved supporting plans, Exceptions, and improvement work.
+- **System and process owners:** Approve access, maintain safeguards, keep inventories and recovery facts current, and resolve findings.
+- **Independent reviewer:** Remains separate from the Policy Owner, approves the Policy, and challenges management's assessment of Control operation.
+
+### Program review
+
+Management reviews the security program on its approved schedule and after material change. Reviews cover objectives, service commitments, applicable duties, fraud and misconduct risk, threats, system and Vendor changes, incidents, findings, Exceptions, overdue work, and Control results. Management documents the participants, cadence, decisions, and follow-up for each review.
+
+### Information and communication
+
+Management obtains or generates, checks, and uses relevant information from internal and external sources to operate and evaluate Controls. Control reports identify their source, scope, period, owner, and known limits when those facts affect a decision. Material security and Control information is communicated in time to the people and outside parties responsible for acting on it.
+
+### Conduct and reporting
+
+Everyone in scope must act honestly, protect company and customer information, follow approved security processes, disclose conflicts that could affect security decisions, and preserve accurate records. Fraud, deliberate Control bypass, false Evidence, credential sharing, unauthorized access, concealment of a security event, and retaliation for a good-faith report are prohibited.
+
+Suspected security events, Control failures, fraud, or policy violations must be reported promptly through the primary route at {{security_contact_email}} or the usable alternate route documented in the Security Incident and Recovery Plan. A person may use the alternate route when the primary route is unavailable, compromised, or involved in the concern. Management investigates credible reports, limits disclosure to people who need the information, preserves relevant records, and records corrective action.
+
+## Risk Management and Compliance Policy
+
+### Obligations and risk assessment
+
+Management identifies security risks and applicable legal, regulatory, contractual, customer, and service commitments, then assigns responsibility through approved requirements, Controls, Systems, Vendor oversight, and governance records. Management obtains qualified legal or other professional advice when an obligation is uncertain.
+
+Risk assessment considers objectives, information, threats, vulnerabilities, fraud, dependencies, service and technology changes, likelihood, impact, existing Controls, and risk tolerance. Risks receive an owner, response, target date, approval when accepted, and a review date. Management reassesses risk on the approved schedule and after material change. Management documents the assessment method, cadence, decisions, and follow-up.
+
+### Control design and review
+
+Management selects and develops manual and technology Controls that respond to approved objectives, commitments, risks, system dependencies, and changes. Each Control has a documented owner, scope, procedure, operating pattern, Evidence source, implementation status, and review path. Management reviews Control design at least annually and after material change, then corrects gaps or records a time-bound Exception.
+
+## Personnel and Human Resources Security Policy
+
+### Responsibilities and screening
+
+Management defines security responsibilities for workers and confirms that people have the competence and authority needed for their assigned duties. Screening or reference checks are performed before sensitive access when lawful, proportionate to the role and risk, and approved by management. Screening is not required when management records that it is unlawful, unavailable, or not warranted for the role.
+
+### Workforce lifecycle
+
+Workers must accept applicable confidentiality, acceptable-use, intellectual-property, and security responsibilities before receiving access. Managers notify access administrators of starts, role changes, extended absences when relevant, and departures. Company property and access are returned, disabled, or removed when employment, services, or business need ends. Management documents approved timing, Evidence, and escalation requirements for onboarding, access changes, and offboarding in supporting procedures and schedules.
+
+### Competence review
+
+Management reviews at least annually and after a material role change whether workers remain capable of their assigned security and Control duties and assigns training, supervision, reassignment, or corrective action when needed. The review may be limited to security and Control responsibilities and does not mandate a broader performance-management process.
+
+## Security Awareness and Training Policy
+
+Workers receive security awareness training on approved onboarding and recurring schedules. Role-specific instruction is assigned when access or duties require it, including for privileged administration, engineering, incident response, privacy, finance, and people operations when applicable.
+
+Training addresses reporting, credential and device protection, data handling, social engineering, acceptable use, incident responsibilities, and current risks relevant to the audience. Completion is tied to the content revision reviewed and followed up when overdue. Management documents the covered population, schedules, acknowledgements, completion, and Evidence in the training program records.
+
+## Acceptable Use, Clear Desk, and Clear Screen Policy
 
 Users must:
 
 - Use approved identities, devices, applications, storage, messaging, meeting, and transfer services.
 - Protect credentials, authentication devices, company equipment, customer information, and security records.
 - Keep company data out of personal accounts and unapproved applications.
-- Lock unattended devices and protect papers, screens, and conversations from unauthorized access.
+- Lock unattended devices and protect papers, screens, conversations, and remote meetings from unauthorized access.
+- Keep Confidential and Restricted information from unattended work areas and dispose of it through approved methods.
 - Report lost, stolen, compromised, or unexpectedly reconfigured devices promptly.
-- Return company property and stop using company access when employment, services, or the business need ends.
+- Return company property and stop using company access when employment, services, or business need ends.
+
+Users must not bypass security safeguards, install unauthorized software, connect unapproved devices or storage, use company Systems for unlawful activity, or disclose information without authorization.
+
+## Asset Management Policy
 
-Managers notify access administrators of starts, role changes, and departures. The Access Control and Offboarding Controls and their event windows record the approved timing, evidence, and escalation rules.
+{{company_name}} inventories important Systems, Components, company and approved personal devices, software, service accounts, Vendors, and data stores. Records identify an owner, purpose, lifecycle state, classification, dependencies, and recovery needs where relevant.
 
-## Assets, data, and retention
+Owners approve assets before they process Confidential or Restricted data or support an important service. Unsupported or unneeded important assets must be upgraded, isolated, replaced, or retired according to risk. Retirement removes company data, software, credentials, access, and inventory assignments through an approved process and retains dated disposal Evidence when the applicable Control requires it.
 
-{{company_name}} inventories important Systems, Components, devices, software, service accounts, Vendors, and data stores. Records identify an owner, purpose, lifecycle state, classification, dependencies, and recovery needs where relevant.
+## Data Classification, Handling, and Protection Policy
+
+### Classification and minimization
 
 Data owners classify information as Public, Internal, Confidential, or Restricted and approve its collection, use, access, storage, sharing, retention, and disposal. When classification is uncertain, users protect the data as Confidential until an owner decides. Collect and retain only information needed for an approved purpose.
 
-Confidential and Restricted data must use approved Systems, encryption in transit over untrusted networks, encryption at rest, least-privilege access, and protected transfer methods. Credentials, private keys, tokens, and recovery codes belong in approved secrets-management Systems and must not appear in source files, tickets, chat, logs, or FileGRC records.
+### Handling and transfer
+
+Confidential and Restricted data must use approved Systems, least-privilege access, protected transfer methods, and safeguards appropriate to its classification and risk. Production data must not enter development or test Systems unless an owner approves the use and equivalent protection. Public links and exports of Confidential or Restricted data require explicit authorization.
+
+### Media, retention, and disposal
+
+Removable media containing Confidential or Restricted data requires owner approval, encryption where supported, controlled custody, and approved disposal. Owners must consider active copies, local copies, media, backups, and Vendor-held copies when applying retention or deletion. Legal holds and active investigations suspend normal disposal for affected records.
+
+The Data Retention Schedule defines the approved period and disposal method for important in-scope record classes. Supporting standards, procedures, and system records document implementation. Disposal must be suitable for the media and classification, with dated proof when the Control requires it.
+
+## Cryptography, Encryption, Key, and Secrets Management Policy
+
+### Encryption requirements
+
+Confidential and Restricted data must use approved encryption in transit over untrusted networks and encryption at rest. Management selects cryptographic methods based on data classification, exposure, technical capability, commitments, and risk, and documents selected methods and configurations in approved standards, procedures, or system records.
+
+### Key and secret management
+
+Encryption keys and other secrets require:
+
+- **Ownership and access:** Named ownership and least-privilege access.
+- **Generation and storage:** Protected generation and storage.
+- **Distribution and use:** Controlled distribution and use.
+- **Rotation and revocation:** Rotation or replacement based on risk and events, and revocation when access or trust ends.
+- **Recovery:** Recoverability when loss would prevent an approved business or recovery process.
+
+Plaintext credentials, private keys, tokens, and recovery codes must not appear in source files, tickets, chat, logs, policy records, audit records, or other general-purpose business records. Source-controlled ciphertext may be used when management approves the encryption method, decryption keys are stored separately in an approved secrets-management System, repository access alone cannot decrypt the material, and access and rotation are controlled.
+
+## Access Control Policy
+
+### Access lifecycle
+
+Access requires a documented business need, owner approval, a unique identity, and least privilege. Authorized administrators provision, change, and remove access. Owners review privileged and production access and other important access on the approved schedules. Dormant, expired, excessive, or unneeded access must be removed.
 
-Production data must not enter development or test Systems unless an owner approves the use and equivalent protection. Public links and exports of Confidential or Restricted data require explicit authorization. Legal holds and active investigations suspend normal disposal for affected records.
+### Privileged, shared, and service accounts
 
-The Data Retention Schedule records the approved period and disposal method for important in-scope record classes. Systems, Controls, and Components record the actual implementation. Disposal must address active copies, local copies, media, backups, and Vendor-held copies where practical, with dated proof when the Control requires it.
+- **Privileged access:** Limited to approved duties and uses separate administrative identities or roles where technically supported and appropriate to risk.
+- **Shared accounts:** Require a documented technical need, named owner, restricted use, protected credentials, and logging.
+- **Service accounts:** Require a named owner, approved purpose, minimum permissions, protected credentials, lifecycle dates or review, and monitoring appropriate to risk.
 
-## Identity and access
+## Identification, Authentication, and Password Policy
 
-Access requires a documented business need, owner approval, a unique identity, and least privilege. Authorized administrators provision, change, and remove access. Shared accounts require a documented technical need, named owner, restricted use, and logging.
+### Authentication and passwords
 
-Multi-factor authentication is required for administrative, production, source-control, email, identity, and Confidential or Restricted data access. When a System cannot support MFA, management must approve a time-bound Exception with risk assessment, compensating Controls, an accountable owner, and a review or expiration date.
+Important Systems use approved strong-authentication settings, unique identities, protected credentials, and safeguards against common authentication attacks. Default credentials must be changed or disabled before use. Only authorized administrators may change authentication and lockout settings.
 
-Authentication settings, privileged roles, service-account ownership, credential protection, access-review populations, review cadence, and removal deadlines belong in the applicable Controls, Components, Systems, and Obligations.
+Passwords and other authenticators must meet settings approved for the System's risk and technical capability. Users must not reuse company passwords in personal services, share authenticators, or store them in plaintext. Systems protect stored authenticators and recovery material against unauthorized disclosure and use. Management documents password length, composition, reuse, lockout, session, and recovery settings in approved authentication standards or System-specific procedures.
 
-## Endpoint, remote work, and physical protection
+### Multi-factor authentication
+
+- **Workforce and administrative access:** MFA is required for access to production, source control, email, identity, and Systems that provide access to Confidential or Restricted data.
+- **Customer and external-user access:** MFA is required when an approved Control, customer commitment, or risk decision requires it.
+- **Exceptions:** Where required MFA is unavailable, management must approve a time-bound Exception with a risk assessment, compensating Controls, an accountable owner, and a review or expiration date.
+
+## Endpoint, Mobile Device, BYOD, and Malware Protection Policy
+
+### Company devices and platform protection
 
 Devices used for company work must run supported software, install security updates, require authentication, lock automatically, use encryption and host protections appropriate to the platform, and permit remote removal when company-managed and technically supported. Users must not disable management, security, logging, encryption, or remote-removal safeguards.
 
-Platforms such as macOS may provide continuous native malware and application protection without a user-triggered full scan. The Endpoint Protection Control describes the continuous protections in use and the periodic process that verifies configuration, update, and compliance state. A scheduled scan applies only when the selected technology and risk decision require one.
+Platforms may provide continuous native malware and application protection without a user-triggered full scan. Management documents the continuous protections in use and the periodic process that verifies configuration, update, and compliance state. A scheduled scan applies only when the selected technology and risk decision require one.
+
+### Personal devices
+
+Personal-device access requires prior approval, registration, verified safeguards, defined company-data boundaries, and exit steps. Management may restrict or prohibit personal-device use based on data, access, legal, customer, support, or recovery needs.
+
+## Remote Access and Remote Work Policy
+
+Remote access to important Systems is limited to authorized users, uses approved encryption and authentication, and is protected in proportion to data, privilege, network trust, and risk. Remote production administration requires MFA and approved access paths. Public or untrusted networks require approved encrypted access and any additional safeguards selected for the risk.
+
+Remote workers must protect devices, papers, screens, calls, home networks, and travel locations. Management documents remote-access configuration and session restrictions in approved standards, procedures, or System records.
+
+## Physical and Environmental Security Policy
+
+Physical access to nonpublic work areas, infrastructure, and protected assets is limited to authorized people. Visitors are controlled and accompanied where sensitive work or information is present. Keys, badges, and other physical access methods are issued, reviewed, recovered, and disabled according to risk.
+
+Owners protect important equipment and media against theft, tampering, damage, and environmental conditions relevant to their location. Facilities supplied by Vendors are addressed through Vendor review, contracts, and assurance rather than unsupported claims about facilities {{company_name}} does not operate.
 
-Personal-device access requires prior approval, registration, verified safeguards, defined company-data boundaries, and exit steps. Remote workers must protect devices, paper, screens, calls, home networks, and travel locations. Public or untrusted networks require approved encrypted access. Physical access to nonpublic work areas and protected assets is limited to authorized people.
+## Network and Communications Security Policy
 
-## Infrastructure and secure change
+Owners restrict inbound, outbound, and internal network paths and management interfaces to approved business needs. They use approved encrypted administrative protocols, disable unnecessary services and ports, protect remote production access, and review material access rules on the approved schedule.
 
-Owners restrict network paths and management interfaces to approved business needs, use encrypted administrative protocols, disable unnecessary defaults and services, protect remote production access, and maintain secure configuration baselines. Deviations require review and, when material, an approved Exception.
+Production, development, test, and general-user environments must be separated to the extent needed for their data, exposure, privileges, and change risk. Connections between environments require approved paths and safeguards. Wireless and other local networks used for company work require authentication and encryption appropriate to current risk and technical capability.
+
+## Configuration Management and System Maintenance Policy
+
+Important Systems and Components use documented secure configuration expectations based on trusted guidance, technical capability, and risk. Owners change or disable unnecessary default accounts, credentials, services, ports, features, and configurations. Deviations require review and, when material, an approved Exception.
+
+Configuration and maintenance work must use authorized access, protect credentials and data, record material changes, and validate security and service behavior. Unsupported important Systems or Components are upgraded, isolated, replaced, or retired according to the Asset Management Policy.
+
+## Secure Development and Change Management Policy
+
+### Change control
 
 Software and infrastructure changes must be recorded, tested, approved, deployed through an authorized process, and recoverable in proportion to risk. Use independent pre-deployment review when practical. When team size or urgency makes that separation impossible, record a risk-appropriate compensating or post-deployment review. Use a time-bound Exception when the remaining departure is material.
 
-Development and deployment Controls address protected branches, controlled credentials, dependency and secret detection, input and authorization checks, production-data restrictions, security testing, emergency change review, and rollback.
+### Security design and development safeguards
+
+Material or high-risk designs and changes receive a documented security analysis suited to the change. This may include threat analysis, abuse cases, architecture review, data-flow review, or another approved method. Based on applicability and risk, Development and deployment Controls address protected branches, controlled credentials, dependency and secret detection, input and authorization checks, production-data restrictions, security testing, emergency change review, deployment approval, communication, and rollback.
+
+## Vulnerability, Patch, and Penetration Testing Policy
+
+### Vulnerability and patch management
+
+{{company_name}} monitors trusted sources for vulnerabilities affecting in-scope Systems and Components. Management selects scanning coverage, penetration-testing applicability, remediation targets, and review cadence from exposure, material change, customer commitments, technical capability, and risk. Management documents the selected coverage, targets, cadence, and review decisions.
+
+Findings receive validated scope, severity, an owner, treatment, and target date. A missed target requires documented exposure, compensating Controls, a revised date, and risk approval or Exception. Security updates are obtained from trusted sources, tested when appropriate, and applied according to the approved risk-based targets.
 
-## Vulnerability, logging, and monitoring
+### Penetration testing
 
-{{company_name}} monitors trusted sources for vulnerabilities affecting in-scope Systems. Management selects scanning coverage, penetration-testing applicability, remediation targets, and review cadence from exposure, change, customer commitments, and risk. The applicable Controls and Obligations record those choices. A missed target requires documented exposure, compensating Controls, a revised date, and risk approval or Exception.
+Penetration testing is performed when an approved Control, customer commitment, material exposure, significant change, or risk decision requires it. Its independence, scope, method, and cadence must fit the reason for testing. This Policy does not require every System to receive an annual penetration test.
 
-Important Systems record and protect the security and operational events needed to investigate misuse and operate the service. Logs use synchronized time, restrict alteration and access, and avoid unnecessary secrets or personal data. Each System's retention period belongs in the approved Data Retention Schedule.
+## Logging, Monitoring, and Audit Trail Policy
 
-Owners define risk-based alerts, review paths, thresholds, and response ownership in Controls, Components, Systems, and governed schedules. Representative alert paths are tested from generation through acknowledgement, escalation, and fallback on the approved schedule and after a material path change.
+### Logging and audit trails
 
-## Incident response, recovery, and continuity
+Important Systems record and protect the security and operational events needed to investigate misuse, operate the service, and meet approved commitments. Depending on risk, events may include authentication activity, privileged actions, identity and access changes, production changes, access to Restricted data, security alerts, and Control failures.
 
-The Security Incident and Recovery Plan defines reporting, alternate access, severity, declaration, roles, containment, evidence handling, notification assessment, communication, recovery, closure, and exercises. Suspected unauthorized access, malware, data loss, credential exposure, or security-Control failure must be reported promptly.
+Logs use synchronized time, restrict alteration and access, and avoid unnecessary secrets or personal data. Each System's retention period belongs in the approved Data Retention Schedule. Owners document risk-based alerts, review paths, thresholds, and response ownership in approved standards, procedures, and schedules.
 
-Each important System records approved continuity objectives, dependencies, a backup or alternate recovery approach, monitoring, and restore-validation needs. The applicable Controls, Components, Systems, and Obligations record the actual frequency, retention, procedures, access owners, and test schedule. Management records incident and recovery exercises, results, findings, and follow-up work.
+### Monitoring and alert testing
 
-## Vendor security
+Systems with availability commitments, recovery objectives, or material operational dependencies monitor the health, capacity, failure, and service indicators needed to detect degradation. Representative alert paths are tested from generation through acknowledgement, escalation, and fallback on the approved schedule and after a material path change. This requirement does not prescribe a particular monitoring or log-management product.
 
-New Vendors receive a risk-based security review and suitable contractual safeguards before access to Confidential or Restricted data. Reviews consider service scope, data, access, assurance, recovery, incident history, dependencies, and contract terms.
+## Incident Response Policy
 
-For a Vendor already in use when this Policy becomes effective, the owner records a transition review and deadline or an approved risk acceptance. Policy adoption does not imply that a historical pre-access review occurred. Vendor monitoring cadence and change-driven reassessment windows belong in the Vendor Controls and Obligations.
+The Security Incident and Recovery Plan defines reporting, alternate access, severity, declaration, roles, containment, Evidence handling, notification assessment, communication, recovery, closure, and exercises. Suspected unauthorized access, malware, data loss, credential exposure, service disruption, or security-Control failure must be reported promptly.
 
-## Exceptions, enforcement, and review
+Reported events receive an owner, assessment, and documented resolution or escalation. Responders preserve relevant Evidence, limit access, coordinate required legal, contractual, privacy, insurance, customer, and regulatory review, validate recovery, and track corrective work. Management exercises the process and representative alert paths on their approved schedules and after material changes when warranted.
+
+## Business Continuity and Disaster Recovery Policy
+
+Each important System records approved recovery priorities and objectives, dependencies, responsible people, alternate communication and access needs, and a backup or alternate recovery approach. Management selects continuity strategies according to service commitments, business impact, data risk, dependencies, and technical capability.
+
+The Security Incident and Recovery Plan records activation, communication, response, recovery, and return-to-normal responsibilities. Management tests continuity and disaster recovery on the approved schedule, records results and findings, and tracks follow-up work.
+
+## Backup and Restoration Policy
+
+Important Systems use backups or an approved alternate recovery approach that meets their recovery objectives. Management documents backup or alternate-recovery scope, frequency, retention, encryption and access needs, monitoring, failure response, procedures, and test schedules.
+
+Backup or recovery access is limited to authorized people and protected from the failures it is intended to address. Restoration or alternate recovery is validated on the approved schedule and after material change when prior results no longer represent the System. Policy adoption does not assert that every System uses daily backups or a fixed retention period.
+
+## Vendor, Third-Party, and Supply Chain Risk Management Policy
+
+### Due diligence
+
+New Vendors receive a risk-based security and privacy review and suitable contractual safeguards before access to Confidential or Restricted data or material reliance by an important service. Reviews consider service scope, data, access, assurance, recovery, incident history, dependencies, supplied Components, and contract terms.
+
+### Contract safeguards
+
+When applicable to the service and risk, contracts address:
+
+- Permitted use and confidentiality.
+- Security responsibilities and incident notice.
+- Access and subprocessor restrictions.
+- Continuity and data return or deletion.
+- Termination.
+- Assurance or audit rights.
+
+Management does not require every term for every Vendor, but records omissions that create material risk or conflict with an approved commitment.
+
+### Existing Vendors and ongoing monitoring
+
+For a Vendor already in use when this Policy becomes effective, the owner records a transition review and deadline or an approved risk acceptance. Policy adoption does not imply that a historical pre-access review occurred. Management documents Vendor monitoring cadence and change-driven reassessment windows in approved Vendor-management procedures and schedules.
+
+## Exceptions, Compliance, Enforcement, and Policy Review
+
+### Exceptions and enforcement
 
 An Exception requires a specific scope and reason, risk assessment, compensating Controls, accountable owner, approval, and expiration or review date. Violations may result in access removal, corrective action, contract remedies, or other action allowed by law and agreement.
 
-The Policy Owner reviews this Policy on the approved governed schedule and after a material change to services, Systems, risks, commitments, or obligations. The independent reviewer approves each revised version. Git history and FileGRC records preserve the reviewed content, approval, activation, and later changes.
+### Policy review
+
+The Policy Owner reviews this Policy on the approved schedule and after a material change to services, Systems, risks, commitments, or obligations. The independent reviewer approves each revised version. The organization retains the reviewed Policy version, approval, effective date, and change history under its document-control process.
+
+### Representations
+
+Questionnaire, customer, auditor, and management representations must reflect the Policy revision, actual Control status, scope, Exceptions, and available Evidence. The presence of this consolidated Policy or one of its section headings does not justify answering that a Control is implemented when it is planned, partial, not applicable, or unsupported by Evidence.

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

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

package/template/package.json

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