create-filegrc 0.1.0

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

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

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

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

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

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

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

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

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

@@ -0,0 +1,29 @@
+{
+  "schemaVersion": 1,
+  "id": "document-incident-response-plan",
+  "type": "document",
+  "title": "Incident Response Plan",
+  "status": "draft",
+  "documentKind": "plan",
+  "ownerIds": ["person-policy-owner"],
+  "approverIds": ["person-independent-approver"],
+  "version": "1.0",
+  "effectiveOn": "{{effective_date}}",
+  "reviewCadence": {
+    "mode": "calendar",
+    "unit": "year",
+    "interval": 1,
+    "anchorDate": "{{effective_date}}"
+  },
+  "classification": "internal",
+  "audience": ["employees", "contractors"],
+  "acknowledgementRequired": false,
+  "controlIds": [
+    "control-security-communication",
+    "control-logging-monitoring",
+    "control-incident-response",
+    "control-incident-exercise"
+  ],
+  "relatedDocumentIds": ["document-business-continuity-disaster-recovery"],
+  "evidenceIds": []
+}

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

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

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

@@ -0,0 +1,17 @@
+{
+  "schemaVersion": 1,
+  "id": "document-soc2-management-assertion",
+  "type": "document",
+  "title": "SOC 2 Management Assertion",
+  "status": "draft",
+  "documentKind": "soc2-management-assertion",
+  "template": true,
+  "ownerIds": [
+    "person-policy-owner"
+  ],
+  "approverIds": [
+    "person-independent-approver"
+  ],
+  "version": "0.1",
+  "classification": "Confidential"
+}

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

@@ -0,0 +1,24 @@
+# {{company_name}} Management Assertion
+
+> Draft preparation document. Reconcile this draft to the wording agreed with the service auditor before approval.
+
+<!-- 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].
+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 -->
+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].
+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.json

@@ -0,0 +1,17 @@
+{
+  "schemaVersion": 1,
+  "id": "document-soc2-management-representation",
+  "type": "document",
+  "title": "SOC 2 Management Representation Letter",
+  "status": "draft",
+  "documentKind": "soc2-management-representation",
+  "template": true,
+  "ownerIds": [
+    "person-policy-owner"
+  ],
+  "approverIds": [
+    "person-independent-approver"
+  ],
+  "version": "0.1",
+  "classification": "Confidential"
+}

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

@@ -0,0 +1,20 @@
+# {{company_name}} Management Representation Letter
+
+> The service auditor normally supplies the required representation-letter wording near the end of fieldwork. Replace this preparation note with the agreed final letter, obtain the required management signature, and retain the signed fixed-format copy as linked evidence.
+
+Before signing, reconcile the auditor's letter to:
+
+- The final system description and management assertion
+- The reporting date or period, [engagement date or period], and selected criteria
+- All service commitments, system requirements, controls, and complementary controls
+- Subservice organizations and the selected presentation method
+- Complete event and control populations supplied to the auditor
+- Known control exceptions, findings, incidents, fraud, legal matters, and significant changes
+- Corrected and uncorrected description or evidence issues
+- Subsequent events through the report date
+
+Final letter received from auditor: [Date]
+
+Management signer and title: [Name and title]
+
+Signed letter evidence record: [Evidence ID]

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

@@ -0,0 +1,17 @@
+{
+  "schemaVersion": 1,
+  "id": "document-soc2-period-completeness",
+  "type": "document",
+  "title": "SOC 2 Period Completeness Statement",
+  "status": "draft",
+  "documentKind": "soc2-period-completeness",
+  "template": true,
+  "ownerIds": [
+    "person-policy-owner"
+  ],
+  "approverIds": [
+    "person-independent-approver"
+  ],
+  "version": "0.1",
+  "classification": "Confidential"
+}

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

@@ -0,0 +1,32 @@
+# {{company_name}} Period Completeness Statement
+
+> Complete this for the exact Type 2 reporting period. It records how management established that both recorded events and zero-event populations are complete.
+
+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.
+
+| Population | FileGRC population ID | Result or exception |
+| --- | --- | --- |
+| Workforce starts, role changes, and departures | [Population ID] | [Result] |
+| Access grants, changes, reviews, and removals | [Population ID] | [Result] |
+| Production and infrastructure changes | [Population ID] | [Result] |
+| Security events and incidents | [Population ID] | [Result] |
+| Vulnerabilities and security scans | [Population ID] | [Result] |
+| Vendors and vendor changes | [Population ID] | [Result] |
+| Devices and other important assets | [Population ID] | [Result] |
+| Training and policy acknowledgements | [Population ID] | [Result] |
+| 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-system export or report that produced the zero count. Describe any source limitation, omitted item, or reconciliation difference below.
+
+## Exceptions and Source Limitations
+
+[None, or explain each exception and its treatment.]
+
+## 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.
+
+[Identify the responsible signer, title, signature or approval method, and date.]

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

@@ -0,0 +1,17 @@
+{
+  "schemaVersion": 1,
+  "id": "document-soc2-system-description",
+  "type": "document",
+  "title": "SOC 2 System Description",
+  "status": "draft",
+  "documentKind": "soc2-system-description",
+  "template": true,
+  "ownerIds": [
+    "person-policy-owner"
+  ],
+  "approverIds": [
+    "person-independent-approver"
+  ],
+  "version": "0.1",
+  "classification": "Internal"
+}

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

@@ -0,0 +1,65 @@
+# {{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.
+
+## Reporting Period and Scope
+
+- Reporting date or period: [engagement date or period]
+- In-scope service: [engagement scope]
+- In-scope systems and environments: [in-scope systems]
+- Trust Services Categories: [selected categories]
+- Subservice organization method: [Carve-out, inclusive, or not applicable]
+
+## DC1: Services Provided
+
+[Describe what the service does, who uses it, and the main service workflows.]
+
+## 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.]
+
+## DC3: System Components
+
+### Infrastructure
+
+[Cloud accounts, networks, compute, storage, facilities, and supporting infrastructure.]
+
+### Software
+
+[Application components, repositories, deployment systems, identity systems, monitoring, and important business software.]
+
+### People
+
+[Teams and roles that develop, operate, secure, support, and oversee the service.]
+
+### Procedures
+
+[The main operating and security procedures that support the controls.]
+
+### Data
+
+[Important data types, classifications, flows, storage locations, retention, and disposal.]
+
+## DC4: Significant System Incidents
+
+[For Type 2, list significant incidents during the period and their effect, or state that management identified none after reconciling the incident population to the authoritative source. For Type 1, describe significant incidents relevant to understanding the system as of the reporting date.]
+
+## DC5: Applicable Criteria and Controls
+
+[Reference the selected criteria and control matrix generated by FileGRC.]
+
+## DC6: Complementary User Entity Controls
+
+[List controls customers must operate for the service controls to work as intended, or explain why none are required.]
+
+## DC7: Subservice Organizations
+
+[List relevant subservice organizations, the services they provide, the selected presentation method, relevant complementary subservice controls, and how they are monitored.]
+
+## DC8: Criteria Not Relevant
+
+[Identify any criteria within an included category that are not relevant and explain why.]
+
+## DC9: Significant Changes
+
+[For Type 2, describe changes during the period that could affect a report user's understanding, or state that management identified none after reconciling the change population. For Type 1, describe significant changes relevant to understanding the system as of the reporting date.]

package/template/data/evidence/AGENTS.md

@@ -0,0 +1,30 @@
+# Evidence Instructions
+
+An evidence record explains what a proof item is, where it came from, what period it supports, who collected it, and which records or controls it supports. The attachment alone is not enough.
+
+## Create evidence
+
+1. Run `npx filegrc guide evidence --json`.
+2. Use one evidence record for one coherent proof item or fixed export.
+3. Put local attachments under `data/evidence/EVIDENCE_ID/` and list their data-relative paths in `filePaths`.
+4. Use `externalReference` only when the file must remain in an approved external system. FileGRC never fetches it.
+5. Link `sourceResourceIds`, `controlIds`, and `auditIds` as applicable. Use `sourceCommit` when the evidence represents repository state.
+6. Name the actual collector. A `verified` record also needs the actual verifier and verification date.
+
+Copy a local fixed file and update the record atomically:
+
+```sh
+npx filegrc attach EVIDENCE_ID /path/to/source-file --name auditor-facing-name.csv
+```
+
+The command never overwrites an existing attachment.
+
+Use `npx filegrc detach EVIDENCE_ID FILE_NAME --yes` when removing a mistaken attachment. FileGRC will not delete an evidence record while local attachments remain.
+
+For a rendered page capture, record the route, filters, audit period, exact Git commit, capture time and method, source resource IDs, and screenshot. A current screenshot cannot prove an earlier state unless it is rendered from or bound to that revision.
+
+For a signed acknowledgement, bind the attestation to the exact content Git revision and store the signed file as evidence.
+
+For a `population-export`, also record the authoritative `sourceSystemId`, 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.

package/template/data/obligation-events/AGENTS.md

@@ -0,0 +1,18 @@
+# Policy Event Instructions
+
+Do not create an `obligation-event` or its action items by hand. Start the configured checklist:
+
+```sh
+npx filegrc obligations --json
+npx filegrc trigger EVENT_TYPE --occurred-on YYYY-MM-DD --subject RESOURCE_ID --json
+```
+
+Use `--occurred-at` with an RFC 3339 timestamp when any action has an hour-based deadline. The command creates the event and full action checklist atomically.
+
+Complete each action with the requested resource type and proof. Then close the workflow:
+
+```sh
+npx filegrc complete-event OBLIGATION_EVENT_ID --completed-on YYYY-MM-DD
+```
+
+FileGRC refuses to close an event with unfinished or unproved actions. Cancel an event only when the triggering event itself was entered in error or did not occur; explain the reason in related records or the commit message.

package/template/data/obligations/AGENTS.md

@@ -0,0 +1,11 @@
+# Obligation Instructions
+
+An obligation is a reusable policy schedule or event template. It is not the record that proves one occurrence happened.
+
+- Calendar obligations need a valid recurrence anchor, owners, expected completion types, and policy or control links.
+- Event obligations need a stable lowercase `eventType`, a prompt, owners, expected completion types, and an explicit deadline window.
+- Keep completed occurrences in `completionResourceIds`. Do not replace prior links when a new period starts.
+- When an approved cadence changes, update the policy, control, and obligation together.
+- Pause or retire a template only when the underlying policy work no longer applies. Do not delete historical templates that explain prior periods.
+
+Use `npx filegrc obligations --json` to inspect calculated work. Use `npx filegrc complete OBLIGATION_ID completion-mutation.json` to create and link a dated occurrence in one validated write.

package/template/data/people/person-independent-approver.json

@@ -0,0 +1,10 @@
+{
+  "schemaVersion": 1,
+  "id": "person-independent-approver",
+  "type": "person",
+  "title": "Independent Approver",
+  "status": "external",
+  "role": "External Security and Risk Oversight Reviewer",
+  "employmentType": "external-reviewer",
+  "teamIds": ["team-security-risk-oversight"]
+}

package/template/data/people/person-policy-owner.json

@@ -0,0 +1,10 @@
+{
+  "schemaVersion": 1,
+  "id": "person-policy-owner",
+  "type": "person",
+  "title": "{{policy_owner_name}}",
+  "status": "active",
+  "email": "{{security_contact_email}}",
+  "role": "Policy Owner",
+  "teamIds": ["team-security-risk-oversight"]
+}

package/template/data/policies/AGENTS.md

@@ -0,0 +1,15 @@
+# Policy Instructions
+
+Policies state required behavior. Controls, obligations, training, attestations, and evidence show how the organization applies that behavior.
+
+Use the `content` Markdown slot for the policy text. Keep ownership and approval metadata in JSON. The approver must be separate from the owner, including through team membership, and must not operate the controls they review.
+
+Keep a policy `draft` until its text, owner, scope, related requirements and controls, approval, effective date, review cadence, and acknowledgement requirement match actual practice. When activating it:
+
+1. Record the real approver and approval date.
+2. Set the effective date.
+3. Link the controls and requirements it supports.
+4. Update or create its recurring and event obligations.
+5. Assign training or attestations when the policy requires them.
+
+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.

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

@@ -0,0 +1,25 @@
+{
+  "schemaVersion": 1,
+  "id": "policy-anti-bribery-corruption",
+  "type": "policy",
+  "title": "Anti-Bribery and Corruption Policy",
+  "status": "draft",
+  "ownerIds": ["person-policy-owner"],
+  "approverIds": ["person-independent-approver"],
+  "policyKind": "corporate-conduct",
+  "version": "1.0",
+  "effectiveOn": "{{effective_date}}",
+  "reviewCadence": {
+    "mode": "calendar",
+    "unit": "year",
+    "interval": 1,
+    "anchorDate": "{{effective_date}}"
+  },
+  "audience": ["employees", "contractors", "agents"],
+  "acknowledgementRequired": true,
+  "controlIds": [
+    "control-security-governance",
+    "control-policy-management",
+    "control-workforce-expectations"
+  ]
+}