create-filegrc 0.6.4 → 0.7.0
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/package.json +1 -1
- package/src/defaults.js +60 -121
- package/src/index.js +12 -11
- package/template/AGENTS.md +8 -3
- package/template/README.md +9 -5
- package/template/data/AGENTS.md +6 -3
- package/template/data/appointments/appointment-policy-owner.json +1 -1
- package/template/data/documents/document-data-retention-schedule.json +1 -1
- package/template/data/documents/document-data-retention-schedule.md +7 -9
- package/template/data/documents/{document-incident-response-plan.json → document-security-incident-recovery-plan.json} +5 -6
- package/template/data/documents/document-security-incident-recovery-plan.md +79 -0
- package/template/data/obligations/AGENTS.md +2 -1
- package/template/data/policies/AGENTS.md +18 -8
- package/template/data/policies/policy-information-security.json +1 -7
- package/template/data/policies/policy-information-security.md +50 -185
- package/template/data/training/training-security-awareness.json +1 -4
- package/template/data/training/training-security-awareness.md +16 -2
- package/template/package.json +1 -1
- package/template/data/documents/document-business-continuity-disaster-recovery.json +0 -29
- package/template/data/documents/document-business-continuity-disaster-recovery.md +0 -192
- package/template/data/documents/document-contractor-policy-acknowledgement.json +0 -20
- package/template/data/documents/document-contractor-policy-acknowledgement.md +0 -24
- package/template/data/documents/document-contractor-training-acknowledgement.json +0 -23
- package/template/data/documents/document-contractor-training-acknowledgement.md +0 -20
- package/template/data/documents/document-employee-handbook-acknowledgement.json +0 -20
- package/template/data/documents/document-employee-handbook-acknowledgement.md +0 -19
- package/template/data/documents/document-employee-policy-acknowledgement.json +0 -20
- package/template/data/documents/document-employee-policy-acknowledgement.md +0 -24
- package/template/data/documents/document-employee-training-acknowledgement.json +0 -23
- package/template/data/documents/document-employee-training-acknowledgement.md +0 -20
- package/template/data/documents/document-incident-response-plan.md +0 -138
- package/template/data/policies/policy-anti-bribery-corruption.json +0 -19
- package/template/data/policies/policy-anti-bribery-corruption.md +0 -87
- package/template/data/policies/policy-clear-desk-screen.json +0 -18
- package/template/data/policies/policy-clear-desk-screen.md +0 -49
- package/template/data/policies/policy-data-protection-handling.json +0 -22
- package/template/data/policies/policy-data-protection-handling.md +0 -130
- package/template/data/policies/policy-employee-handbook.json +0 -21
- package/template/data/policies/policy-employee-handbook.md +0 -161
- package/template/data/policies/policy-mobile-computing-communications.json +0 -18
- package/template/data/policies/policy-mobile-computing-communications.md +0 -74
- package/template/data/training/training-anti-bribery-high-risk-roles.json +0 -16
- package/template/data/training/training-anti-bribery-high-risk-roles.md +0 -19
- package/template/data/training/training-privileged-sensitive-roles.json +0 -20
- package/template/data/training/training-privileged-sensitive-roles.md +0 -20
- package/template/data/training/training-secure-development.json +0 -19
- package/template/data/training/training-secure-development.md +0 -22
|
@@ -1,24 +0,0 @@
|
|
|
1
|
-
# Contractor Policy Acknowledgement
|
|
2
|
-
|
|
3
|
-
I acknowledge that I received access to the following {{company_name}} documents:
|
|
4
|
-
|
|
5
|
-
- Anti-Bribery and Corruption Policy
|
|
6
|
-
- Business Continuity and Disaster Recovery Plan
|
|
7
|
-
- Clear Desk and Clear Screen Policy
|
|
8
|
-
- Data Protection and Handling Policy
|
|
9
|
-
- Information Security Policy
|
|
10
|
-
- Mobile Computing and Communications Policy
|
|
11
|
-
|
|
12
|
-
I understand that I am responsible for following these documents while performing services for {{company_name}}, protecting information made available to me, and reporting suspected violations.
|
|
13
|
-
|
|
14
|
-
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.
|
|
15
|
-
|
|
16
|
-
This acknowledgement supplements and does not replace the applicable services, confidentiality, or data-protection agreement.
|
|
17
|
-
|
|
18
|
-
Content Git commit: ___________________________________
|
|
19
|
-
|
|
20
|
-
Contractor name: ____________________________________
|
|
21
|
-
|
|
22
|
-
Signature: __________________________________________
|
|
23
|
-
|
|
24
|
-
Date: ______________________________________________
|
|
@@ -1,23 +0,0 @@
|
|
|
1
|
-
{
|
|
2
|
-
"id": "document-contractor-training-acknowledgement",
|
|
3
|
-
"type": "document",
|
|
4
|
-
"title": "Contractor Training Acknowledgement",
|
|
5
|
-
"status": "draft",
|
|
6
|
-
"documentKind": "attestation-template",
|
|
7
|
-
"ownerIds": [
|
|
8
|
-
"appointment-policy-owner"
|
|
9
|
-
],
|
|
10
|
-
"version": "1.0",
|
|
11
|
-
"audience": [
|
|
12
|
-
"contractors"
|
|
13
|
-
],
|
|
14
|
-
"controlIds": [
|
|
15
|
-
"control-security-training"
|
|
16
|
-
],
|
|
17
|
-
"trainingIds": [
|
|
18
|
-
"training-security-awareness"
|
|
19
|
-
],
|
|
20
|
-
"classificationId": "internal",
|
|
21
|
-
"proposedEffectiveOn": "{{effective_date}}",
|
|
22
|
-
"programRole": "conditional"
|
|
23
|
-
}
|
|
@@ -1,20 +0,0 @@
|
|
|
1
|
-
# Contractor Training Acknowledgement
|
|
2
|
-
|
|
3
|
-
I acknowledge that I completed the following {{company_name}} training:
|
|
4
|
-
|
|
5
|
-
- Security Awareness and Incident Response Training
|
|
6
|
-
- Other assigned training: ______________________________
|
|
7
|
-
|
|
8
|
-
I understand the security responsibilities and reporting process described in the training. I had an opportunity to ask questions, and I will follow the policies and procedures that apply to the services I perform.
|
|
9
|
-
|
|
10
|
-
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.
|
|
11
|
-
|
|
12
|
-
This acknowledgement supplements and does not replace the applicable services, confidentiality, data-protection, or other written agreement.
|
|
13
|
-
|
|
14
|
-
Training Git commit: __________________________________
|
|
15
|
-
|
|
16
|
-
Contractor name: ____________________________________
|
|
17
|
-
|
|
18
|
-
Signature: __________________________________________
|
|
19
|
-
|
|
20
|
-
Date: ______________________________________________
|
|
@@ -1,20 +0,0 @@
|
|
|
1
|
-
{
|
|
2
|
-
"id": "document-employee-handbook-acknowledgement",
|
|
3
|
-
"type": "document",
|
|
4
|
-
"title": "Employee Handbook Acknowledgement",
|
|
5
|
-
"status": "draft",
|
|
6
|
-
"documentKind": "attestation-template",
|
|
7
|
-
"ownerIds": [
|
|
8
|
-
"appointment-policy-owner"
|
|
9
|
-
],
|
|
10
|
-
"version": "1.0",
|
|
11
|
-
"audience": [
|
|
12
|
-
"employees"
|
|
13
|
-
],
|
|
14
|
-
"controlIds": [
|
|
15
|
-
"control-workforce-expectations"
|
|
16
|
-
],
|
|
17
|
-
"classificationId": "internal",
|
|
18
|
-
"proposedEffectiveOn": "{{effective_date}}",
|
|
19
|
-
"programRole": "conditional"
|
|
20
|
-
}
|
|
@@ -1,19 +0,0 @@
|
|
|
1
|
-
# Employee Handbook Acknowledgement
|
|
2
|
-
|
|
3
|
-
I acknowledge that I received access to the current {{company_name}} Employee Handbook.
|
|
4
|
-
|
|
5
|
-
I understand that I am responsible for reading the handbook, asking questions when a requirement is unclear, and following the requirements that apply to my work.
|
|
6
|
-
|
|
7
|
-
I understand the reporting routes and the prohibition on retaliation for a good-faith report, accommodation request, safety concern, pay concern, or participation in a review.
|
|
8
|
-
|
|
9
|
-
I understand that the handbook is not an employment contract. Local law, written employment terms, benefit plans, and approved regional supplements control when they differ from the handbook.
|
|
10
|
-
|
|
11
|
-
I understand that the handbook may be updated. When {{company_name}} requires a new acknowledgement, I will review the identified revision before signing. The Git commit below identifies the exact handbook revision covered by this acknowledgement.
|
|
12
|
-
|
|
13
|
-
Handbook Git commit: __________________________________
|
|
14
|
-
|
|
15
|
-
Employee name: ______________________________________
|
|
16
|
-
|
|
17
|
-
Signature: __________________________________________
|
|
18
|
-
|
|
19
|
-
Date: ______________________________________________
|
|
@@ -1,20 +0,0 @@
|
|
|
1
|
-
{
|
|
2
|
-
"id": "document-employee-policy-acknowledgement",
|
|
3
|
-
"type": "document",
|
|
4
|
-
"title": "Employee Policy Acknowledgement",
|
|
5
|
-
"status": "draft",
|
|
6
|
-
"documentKind": "attestation-template",
|
|
7
|
-
"ownerIds": [
|
|
8
|
-
"appointment-policy-owner"
|
|
9
|
-
],
|
|
10
|
-
"version": "1.0",
|
|
11
|
-
"audience": [
|
|
12
|
-
"employees"
|
|
13
|
-
],
|
|
14
|
-
"controlIds": [
|
|
15
|
-
"control-workforce-expectations"
|
|
16
|
-
],
|
|
17
|
-
"classificationId": "internal",
|
|
18
|
-
"proposedEffectiveOn": "{{effective_date}}",
|
|
19
|
-
"programRole": "conditional"
|
|
20
|
-
}
|
|
@@ -1,24 +0,0 @@
|
|
|
1
|
-
# Employee Policy Acknowledgement
|
|
2
|
-
|
|
3
|
-
I acknowledge that I received access to the following {{company_name}} documents:
|
|
4
|
-
|
|
5
|
-
- Anti-Bribery and Corruption Policy
|
|
6
|
-
- Business Continuity and Disaster Recovery Plan
|
|
7
|
-
- Clear Desk and Clear Screen Policy
|
|
8
|
-
- Data Protection and Handling Policy
|
|
9
|
-
- Information Security Policy
|
|
10
|
-
- Mobile Computing and Communications Policy
|
|
11
|
-
|
|
12
|
-
I understand that I am responsible for reading and following these documents, asking questions when a requirement is unclear, and reporting suspected violations.
|
|
13
|
-
|
|
14
|
-
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.
|
|
15
|
-
|
|
16
|
-
This acknowledgement does not change the terms of employment or create a contract where one does not otherwise exist.
|
|
17
|
-
|
|
18
|
-
Content Git commit: ___________________________________
|
|
19
|
-
|
|
20
|
-
Employee name: ______________________________________
|
|
21
|
-
|
|
22
|
-
Signature: __________________________________________
|
|
23
|
-
|
|
24
|
-
Date: ______________________________________________
|
|
@@ -1,23 +0,0 @@
|
|
|
1
|
-
{
|
|
2
|
-
"id": "document-employee-training-acknowledgement",
|
|
3
|
-
"type": "document",
|
|
4
|
-
"title": "Employee Training Acknowledgement",
|
|
5
|
-
"status": "draft",
|
|
6
|
-
"documentKind": "attestation-template",
|
|
7
|
-
"ownerIds": [
|
|
8
|
-
"appointment-policy-owner"
|
|
9
|
-
],
|
|
10
|
-
"version": "1.0",
|
|
11
|
-
"audience": [
|
|
12
|
-
"employees"
|
|
13
|
-
],
|
|
14
|
-
"controlIds": [
|
|
15
|
-
"control-security-training"
|
|
16
|
-
],
|
|
17
|
-
"trainingIds": [
|
|
18
|
-
"training-security-awareness"
|
|
19
|
-
],
|
|
20
|
-
"classificationId": "internal",
|
|
21
|
-
"proposedEffectiveOn": "{{effective_date}}",
|
|
22
|
-
"programRole": "conditional"
|
|
23
|
-
}
|
|
@@ -1,20 +0,0 @@
|
|
|
1
|
-
# Employee Training Acknowledgement
|
|
2
|
-
|
|
3
|
-
I acknowledge that I completed the following {{company_name}} training:
|
|
4
|
-
|
|
5
|
-
- Security Awareness and Incident Response Training
|
|
6
|
-
- Other assigned training: ______________________________
|
|
7
|
-
|
|
8
|
-
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.
|
|
9
|
-
|
|
10
|
-
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.
|
|
11
|
-
|
|
12
|
-
This acknowledgement confirms completion of assigned training. It does not create an employment contract or change written employment terms.
|
|
13
|
-
|
|
14
|
-
Training Git commit: __________________________________
|
|
15
|
-
|
|
16
|
-
Employee name: ______________________________________
|
|
17
|
-
|
|
18
|
-
Signature: __________________________________________
|
|
19
|
-
|
|
20
|
-
Date: ______________________________________________
|
|
@@ -1,138 +0,0 @@
|
|
|
1
|
-
# Incident Response Plan
|
|
2
|
-
|
|
3
|
-
## Purpose
|
|
4
|
-
|
|
5
|
-
This plan defines how {{company_name}} identifies, declares, contains, investigates, communicates, recovers from, and learns from security incidents.
|
|
6
|
-
|
|
7
|
-
## Scope
|
|
8
|
-
|
|
9
|
-
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.
|
|
10
|
-
|
|
11
|
-
Questions and incident reports should be sent immediately to {{security_contact_email}}. If that route is unavailable or may be compromised, contact the current Policy Owner through a known alternate channel.
|
|
12
|
-
|
|
13
|
-
## Definitions
|
|
14
|
-
|
|
15
|
-
A **security event** is an observable occurrence that may affect the confidentiality, integrity, or availability of systems or information.
|
|
16
|
-
|
|
17
|
-
A **security incident** is a security event that requires coordinated investigation, containment, recovery, or communication.
|
|
18
|
-
|
|
19
|
-
A **material incident** is an incident that:
|
|
20
|
-
|
|
21
|
-
- Causes or is reasonably likely to cause significant harm to customers, workers, operations, systems, or data
|
|
22
|
-
- Causes a significant failure to meet a service commitment or system requirement
|
|
23
|
-
- Results from a material control failure
|
|
24
|
-
- Requires notice to a customer, regulator, insurer, or another outside party
|
|
25
|
-
- Is designated material by the incident lead or executive sponsor based on the known facts
|
|
26
|
-
|
|
27
|
-
Critical and High incidents are material unless the incident lead records why they are not. A lower-severity incident may still be material.
|
|
28
|
-
|
|
29
|
-
## Severity
|
|
30
|
-
|
|
31
|
-
The incident lead assigns an initial severity during triage and updates it as facts change.
|
|
32
|
-
|
|
33
|
-
| Severity | General criteria | Response posture |
|
|
34
|
-
| --- | --- | --- |
|
|
35
|
-
| 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 |
|
|
36
|
-
| 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 |
|
|
37
|
-
| 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 |
|
|
38
|
-
| Low | Security event requiring investigation or corrective work with little realized impact | Assigned owner, documented resolution, and trend review where useful |
|
|
39
|
-
|
|
40
|
-
Severity considers affected data, systems, customers, privileges, duration, spread, exploitability, business impact, and notification duties. Every severity change records the reason and time.
|
|
41
|
-
|
|
42
|
-
## Roles and authority
|
|
43
|
-
|
|
44
|
-
These names describe response functions, not required job titles or separate Appointments. The current Policy Owner performs them by default and management delegates a function only when that matches how the organization actually responds.
|
|
45
|
-
|
|
46
|
-
### Reporter
|
|
47
|
-
|
|
48
|
-
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.
|
|
49
|
-
|
|
50
|
-
### Incident lead
|
|
51
|
-
|
|
52
|
-
The incident lead declares the incident, assigns severity, coordinates work, maintains the incident record, approves status changes, and decides when the incident is contained and closed. The current Policy Owner acts as incident lead until another qualified person is assigned.
|
|
53
|
-
|
|
54
|
-
### Technical responders
|
|
55
|
-
|
|
56
|
-
Technical responders investigate, contain, preserve evidence, remove the cause, restore service, and validate affected systems under the incident lead's direction.
|
|
57
|
-
|
|
58
|
-
### System and process owners
|
|
59
|
-
|
|
60
|
-
Owners explain business impact, dependencies, data, customer commitments, and recovery needs. They approve restored operation and remaining risk within their authority.
|
|
61
|
-
|
|
62
|
-
### Executive sponsor
|
|
63
|
-
|
|
64
|
-
The executive sponsor makes decisions beyond the incident lead's authority, accepts material residual risk, and approves material external communications.
|
|
65
|
-
|
|
66
|
-
### Legal, privacy, insurance, and communications owners
|
|
67
|
-
|
|
68
|
-
The responsible owners assess notification duties, preserve privilege where applicable, coordinate required third parties, and approve communications within their authority.
|
|
69
|
-
|
|
70
|
-
## Reporting and declaration
|
|
71
|
-
|
|
72
|
-
Report suspected phishing, malware, unauthorized access, credential exposure, data loss, unintended disclosure, security-control failure, or other security harm immediately.
|
|
73
|
-
|
|
74
|
-
The incident lead records:
|
|
75
|
-
|
|
76
|
-
- The report, detection time, and known occurrence time
|
|
77
|
-
- Affected systems, identities, data, customers, locations, and vendors
|
|
78
|
-
- Initial impact, severity, and materiality decision
|
|
79
|
-
- Response participants and assigned owners
|
|
80
|
-
- Evidence sources and preservation actions
|
|
81
|
-
- Decisions, actions, communications, and timestamps
|
|
82
|
-
- Required notifications and their owners and deadlines
|
|
83
|
-
- Recovery status, remaining risk, and follow-up work
|
|
84
|
-
|
|
85
|
-
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.
|
|
86
|
-
|
|
87
|
-
## Response
|
|
88
|
-
|
|
89
|
-
The incident lead coordinates these activities in the order appropriate to the incident:
|
|
90
|
-
|
|
91
|
-
1. Validate the report and assign an initial severity.
|
|
92
|
-
2. Protect people and contain continuing harm.
|
|
93
|
-
3. Preserve evidence and establish a reliable incident timeline.
|
|
94
|
-
4. Identify affected systems, data, identities, customers, and dependencies.
|
|
95
|
-
5. Remove the cause and close the path used by the incident.
|
|
96
|
-
6. Recover systems and data through approved procedures.
|
|
97
|
-
7. Validate security, integrity, monitoring, and expected operation.
|
|
98
|
-
8. Complete required internal and external communications.
|
|
99
|
-
9. Monitor for recurrence.
|
|
100
|
-
10. Close the incident after owners accept the restored state and remaining risk.
|
|
101
|
-
|
|
102
|
-
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.
|
|
103
|
-
|
|
104
|
-
## Evidence and investigation
|
|
105
|
-
|
|
106
|
-
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.
|
|
107
|
-
|
|
108
|
-
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.
|
|
109
|
-
|
|
110
|
-
## Communications and notification
|
|
111
|
-
|
|
112
|
-
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.
|
|
113
|
-
|
|
114
|
-
For each potential external notice, the responsible owner records:
|
|
115
|
-
|
|
116
|
-
- The triggering law, contract, policy, or commitment
|
|
117
|
-
- The affected audience and known facts
|
|
118
|
-
- The decision-maker and communication owner
|
|
119
|
-
- The deadline and the event that started the deadline
|
|
120
|
-
- The decision, approval, delivery time, and retained evidence
|
|
121
|
-
|
|
122
|
-
Communications distinguish confirmed facts from estimates, avoid unsupported claims, and preserve confidentiality.
|
|
123
|
-
|
|
124
|
-
## Recovery and closure
|
|
125
|
-
|
|
126
|
-
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.
|
|
127
|
-
|
|
128
|
-
Closure requires a final severity and materiality decision, an incident summary, disposition of notification duties, linked evidence, and assigned follow-up work.
|
|
129
|
-
|
|
130
|
-
## Review and exercises
|
|
131
|
-
|
|
132
|
-
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.
|
|
133
|
-
|
|
134
|
-
{{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.
|
|
135
|
-
|
|
136
|
-
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.
|
|
137
|
-
|
|
138
|
-
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.
|
|
@@ -1,19 +0,0 @@
|
|
|
1
|
-
{
|
|
2
|
-
"id": "policy-anti-bribery-corruption",
|
|
3
|
-
"type": "policy",
|
|
4
|
-
"title": "Anti-Bribery and Corruption Policy",
|
|
5
|
-
"status": "draft",
|
|
6
|
-
"ownerIds": [
|
|
7
|
-
"appointment-policy-owner"
|
|
8
|
-
],
|
|
9
|
-
"policyKind": "corporate-conduct",
|
|
10
|
-
"version": "1.0",
|
|
11
|
-
"audience": [
|
|
12
|
-
"employees",
|
|
13
|
-
"contractors",
|
|
14
|
-
"agents"
|
|
15
|
-
],
|
|
16
|
-
"acknowledgementRequired": true,
|
|
17
|
-
"proposedEffectiveOn": "{{effective_date}}",
|
|
18
|
-
"programRole": "conditional"
|
|
19
|
-
}
|
|
@@ -1,87 +0,0 @@
|
|
|
1
|
-
# Anti-Bribery and Corruption Policy
|
|
2
|
-
|
|
3
|
-
## Purpose
|
|
4
|
-
|
|
5
|
-
{{company_name}} conducts business honestly and complies with applicable anti-bribery and anti-corruption laws. No business result justifies offering, requesting, accepting, or concealing an improper payment or benefit.
|
|
6
|
-
|
|
7
|
-
## Scope
|
|
8
|
-
|
|
9
|
-
This policy applies to employees, contractors, officers, directors, agents, consultants, and third parties acting for {{company_name}}.
|
|
10
|
-
|
|
11
|
-
## Prohibited conduct
|
|
12
|
-
|
|
13
|
-
Covered persons must not directly or indirectly:
|
|
14
|
-
|
|
15
|
-
- Offer, promise, authorize, give, request, or accept anything of value to improperly influence a decision.
|
|
16
|
-
- Reward someone for misusing a position of trust.
|
|
17
|
-
- Use a third party to do something this policy prohibits.
|
|
18
|
-
- Make facilitation or expediting payments, except when necessary to prevent an immediate threat to health or safety.
|
|
19
|
-
- Create false, incomplete, misleading, or undisclosed records.
|
|
20
|
-
- Retaliate against someone who raises a concern in good faith.
|
|
21
|
-
|
|
22
|
-
"Anything of value" includes money, gifts, meals, travel, entertainment, discounts, services, employment opportunities, charitable contributions, political contributions, and benefits provided to a recipient's family or associates.
|
|
23
|
-
|
|
24
|
-
## Government officials
|
|
25
|
-
|
|
26
|
-
Interactions with government officials require added care. The term includes elected and appointed officials, employees of government agencies or state-controlled entities, political candidates, public international organizations, and anyone acting in an official capacity.
|
|
27
|
-
|
|
28
|
-
No payment, gift, or benefit may be offered to a government official to obtain or retain business, avoid a requirement, influence an official act, or secure an improper advantage.
|
|
29
|
-
|
|
30
|
-
## Gifts, meals, travel, and entertainment
|
|
31
|
-
|
|
32
|
-
Business courtesies must:
|
|
33
|
-
|
|
34
|
-
- Have a legitimate business purpose.
|
|
35
|
-
- Be reasonable, infrequent, and appropriate to the circumstances.
|
|
36
|
-
- Comply with the recipient's rules and applicable law.
|
|
37
|
-
- Never consist of cash or a cash equivalent.
|
|
38
|
-
- Never be intended to influence a pending decision.
|
|
39
|
-
- Be recorded accurately when {{company_name}} pays for them.
|
|
40
|
-
|
|
41
|
-
The policy owner must approve any courtesy that could reasonably appear improper.
|
|
42
|
-
|
|
43
|
-
## Political and charitable contributions
|
|
44
|
-
|
|
45
|
-
Company funds, property, or services may not be used for political contributions without written approval from the policy owner and confirmation that the contribution is lawful.
|
|
46
|
-
|
|
47
|
-
Charitable contributions must have a documented charitable purpose and may not benefit a decision-maker personally or act as a substitute for an improper payment.
|
|
48
|
-
|
|
49
|
-
## Third parties
|
|
50
|
-
|
|
51
|
-
Before engaging an agent, consultant, reseller, or other intermediary who may interact with customers or officials on {{company_name}}'s behalf, the responsible owner must:
|
|
52
|
-
|
|
53
|
-
1. Perform risk-based due diligence.
|
|
54
|
-
2. Confirm the service and compensation are commercially reasonable.
|
|
55
|
-
3. Use a written agreement describing the service and requiring lawful conduct.
|
|
56
|
-
4. Approve and retain invoices and supporting records.
|
|
57
|
-
5. Monitor for unusual requests, payment methods, or relationships.
|
|
58
|
-
|
|
59
|
-
Warning signs must be resolved before engagement or payment. Examples include:
|
|
60
|
-
|
|
61
|
-
- A request for payment to an unrelated person, unusual account, or country unrelated to the work.
|
|
62
|
-
- Vague services, excessive commissions, or invoices that do not match the agreement.
|
|
63
|
-
- A close relationship with a government official or decision-maker.
|
|
64
|
-
- Refusal to complete due diligence or sign appropriate contract terms.
|
|
65
|
-
- A request to hide a person's identity, role, or the purpose of a transaction.
|
|
66
|
-
|
|
67
|
-
## Books and records
|
|
68
|
-
|
|
69
|
-
Transactions must be recorded promptly, accurately, and with enough detail to explain their purpose. Undisclosed accounts, false descriptions, fabricated invoices, and off-book transactions are prohibited.
|
|
70
|
-
|
|
71
|
-
## Reporting
|
|
72
|
-
|
|
73
|
-
Report questions, suspected violations, requests for improper payments, or inaccurate records to the current Policy Owner at {{security_contact_email}}. Reports may be made without first notifying a manager.
|
|
74
|
-
|
|
75
|
-
{{company_name}} prohibits retaliation against anyone who reports a concern or participates in an investigation in good faith.
|
|
76
|
-
|
|
77
|
-
## Investigations and enforcement
|
|
78
|
-
|
|
79
|
-
{{company_name}} will review credible reports promptly and limit disclosure to people who need the information. Covered persons must preserve relevant records and cooperate honestly.
|
|
80
|
-
|
|
81
|
-
Violations may result in removal of authority, termination of a contract or employment relationship, recovery of funds, and referral to authorities when appropriate.
|
|
82
|
-
|
|
83
|
-
## Training and review
|
|
84
|
-
|
|
85
|
-
People in higher-risk roles complete assigned anti-bribery training within 30 days of starting those duties or changing into a covered role. Covered roles include work involving sales, procurement, payments, gifts or hospitality, government interaction, higher-risk locations, or third parties acting for {{company_name}}. The onboarding or role-change checklist records the training assignment or why it does not apply.
|
|
86
|
-
|
|
87
|
-
This policy is reviewed at least annually and after a material legal, geographic, or business change.
|
|
@@ -1,18 +0,0 @@
|
|
|
1
|
-
{
|
|
2
|
-
"id": "policy-clear-desk-screen",
|
|
3
|
-
"type": "policy",
|
|
4
|
-
"title": "Clear Desk and Clear Screen Policy",
|
|
5
|
-
"status": "draft",
|
|
6
|
-
"ownerIds": [
|
|
7
|
-
"appointment-policy-owner"
|
|
8
|
-
],
|
|
9
|
-
"policyKind": "information-security",
|
|
10
|
-
"version": "1.0",
|
|
11
|
-
"audience": [
|
|
12
|
-
"employees",
|
|
13
|
-
"contractors"
|
|
14
|
-
],
|
|
15
|
-
"acknowledgementRequired": true,
|
|
16
|
-
"proposedEffectiveOn": "{{effective_date}}",
|
|
17
|
-
"programRole": "alternative"
|
|
18
|
-
}
|
|
@@ -1,49 +0,0 @@
|
|
|
1
|
-
# Clear Desk and Clear Screen Policy
|
|
2
|
-
|
|
3
|
-
## Purpose
|
|
4
|
-
|
|
5
|
-
{{company_name}} protects confidential information from accidental exposure, theft, and unauthorized access in offices, shared spaces, and remote work locations.
|
|
6
|
-
|
|
7
|
-
## Scope
|
|
8
|
-
|
|
9
|
-
This policy applies to employees and contractors who handle company, customer, workforce, or vendor information.
|
|
10
|
-
|
|
11
|
-
## Clear desk requirements
|
|
12
|
-
|
|
13
|
-
When a workspace is unattended:
|
|
14
|
-
|
|
15
|
-
- Store confidential papers and removable media in a locked or access-controlled location.
|
|
16
|
-
- Remove passwords, access codes, keys, badges, and authentication devices from view.
|
|
17
|
-
- Do not leave payment information, identity documents, contracts, customer lists, or personnel records exposed.
|
|
18
|
-
- Retrieve sensitive print jobs immediately.
|
|
19
|
-
- Dispose of sensitive paper in an approved secure-destruction container.
|
|
20
|
-
- Return shared meeting rooms and work areas to a clean state.
|
|
21
|
-
- Secure portable equipment with a physical lock or security cable where practical.
|
|
22
|
-
|
|
23
|
-
At the end of the workday, secure confidential material and company equipment.
|
|
24
|
-
|
|
25
|
-
## Clear screen requirements
|
|
26
|
-
|
|
27
|
-
- Lock the screen whenever leaving a device unattended.
|
|
28
|
-
- Configure automatic screen locking after no more than 15 minutes of inactivity.
|
|
29
|
-
- Position screens to reduce unnecessary viewing by visitors or the public.
|
|
30
|
-
- Use a privacy screen when confidential information must be viewed in a public or shared location.
|
|
31
|
-
- Close files and applications that are no longer needed.
|
|
32
|
-
- Do not display passwords, secrets, or recovery codes on monitors or notes.
|
|
33
|
-
- Do not leave sensitive files, shortcuts, diagrams, or other information exposed on a shared desktop or display.
|
|
34
|
-
|
|
35
|
-
## Remote work
|
|
36
|
-
|
|
37
|
-
Remote workers must choose a workspace where household members, visitors, and the public cannot casually view or access confidential information. Voice and video calls involving confidential matters must be conducted where they cannot be overheard.
|
|
38
|
-
|
|
39
|
-
## Visitors
|
|
40
|
-
|
|
41
|
-
Visitors must remain in authorized areas and be supervised where confidential information or systems are present. Hosts are responsible for clearing exposed information before a visitor arrives.
|
|
42
|
-
|
|
43
|
-
## Lost material or suspected exposure
|
|
44
|
-
|
|
45
|
-
Report lost papers, devices, badges, removable media, or suspected unauthorized viewing immediately to the current Policy Owner at {{security_contact_email}}.
|
|
46
|
-
|
|
47
|
-
## Enforcement and review
|
|
48
|
-
|
|
49
|
-
Failure to follow this policy may lead to access restrictions or disciplinary action. The policy owner reviews this policy at least annually.
|
|
@@ -1,22 +0,0 @@
|
|
|
1
|
-
{
|
|
2
|
-
"id": "policy-data-protection-handling",
|
|
3
|
-
"type": "policy",
|
|
4
|
-
"title": "Data Protection and Handling Policy",
|
|
5
|
-
"status": "draft",
|
|
6
|
-
"ownerIds": [
|
|
7
|
-
"appointment-policy-owner"
|
|
8
|
-
],
|
|
9
|
-
"policyKind": "information-security",
|
|
10
|
-
"version": "1.0",
|
|
11
|
-
"audience": [
|
|
12
|
-
"employees",
|
|
13
|
-
"contractors",
|
|
14
|
-
"vendors"
|
|
15
|
-
],
|
|
16
|
-
"acknowledgementRequired": true,
|
|
17
|
-
"relatedDocumentIds": [
|
|
18
|
-
"document-data-retention-schedule"
|
|
19
|
-
],
|
|
20
|
-
"proposedEffectiveOn": "{{effective_date}}",
|
|
21
|
-
"programRole": "required"
|
|
22
|
-
}
|