create-filegrc 0.6.5 → 0.7.1

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.
Files changed (56) hide show
  1. package/README.md +1 -1
  2. package/package.json +1 -1
  3. package/src/defaults.js +128 -145
  4. package/src/index.js +12 -11
  5. package/template/AGENTS.md +17 -6
  6. package/template/README.md +14 -6
  7. package/template/WORKSPACE.md +2 -0
  8. package/template/data/AGENTS.md +12 -7
  9. package/template/data/appointments/appointment-policy-owner.json +1 -1
  10. package/template/data/audits/AGENTS.md +10 -0
  11. package/template/data/documents/AGENTS.md +11 -0
  12. package/template/data/documents/document-data-retention-schedule.json +1 -1
  13. package/template/data/documents/document-data-retention-schedule.md +7 -9
  14. package/template/data/documents/{document-incident-response-plan.json → document-security-incident-recovery-plan.json} +5 -6
  15. package/template/data/documents/document-security-incident-recovery-plan.md +79 -0
  16. package/template/data/documents/document-soc2-management-assertion.md +7 -7
  17. package/template/data/documents/document-soc2-management-representation.md +1 -1
  18. package/template/data/documents/document-soc2-period-completeness.md +4 -4
  19. package/template/data/documents/document-soc2-system-description.md +4 -4
  20. package/template/data/evidence/AGENTS.md +1 -1
  21. package/template/data/obligations/AGENTS.md +2 -1
  22. package/template/data/policies/AGENTS.md +22 -8
  23. package/template/data/policies/policy-information-security.json +2 -9
  24. package/template/data/policies/policy-information-security.md +205 -148
  25. package/template/data/training/training-security-awareness.json +1 -4
  26. package/template/data/training/training-security-awareness.md +20 -6
  27. package/template/package.json +1 -1
  28. package/template/data/documents/document-business-continuity-disaster-recovery.json +0 -29
  29. package/template/data/documents/document-business-continuity-disaster-recovery.md +0 -192
  30. package/template/data/documents/document-contractor-policy-acknowledgement.json +0 -20
  31. package/template/data/documents/document-contractor-policy-acknowledgement.md +0 -24
  32. package/template/data/documents/document-contractor-training-acknowledgement.json +0 -23
  33. package/template/data/documents/document-contractor-training-acknowledgement.md +0 -20
  34. package/template/data/documents/document-employee-handbook-acknowledgement.json +0 -20
  35. package/template/data/documents/document-employee-handbook-acknowledgement.md +0 -19
  36. package/template/data/documents/document-employee-policy-acknowledgement.json +0 -20
  37. package/template/data/documents/document-employee-policy-acknowledgement.md +0 -24
  38. package/template/data/documents/document-employee-training-acknowledgement.json +0 -23
  39. package/template/data/documents/document-employee-training-acknowledgement.md +0 -20
  40. package/template/data/documents/document-incident-response-plan.md +0 -138
  41. package/template/data/policies/policy-anti-bribery-corruption.json +0 -19
  42. package/template/data/policies/policy-anti-bribery-corruption.md +0 -87
  43. package/template/data/policies/policy-clear-desk-screen.json +0 -18
  44. package/template/data/policies/policy-clear-desk-screen.md +0 -49
  45. package/template/data/policies/policy-data-protection-handling.json +0 -22
  46. package/template/data/policies/policy-data-protection-handling.md +0 -130
  47. package/template/data/policies/policy-employee-handbook.json +0 -21
  48. package/template/data/policies/policy-employee-handbook.md +0 -161
  49. package/template/data/policies/policy-mobile-computing-communications.json +0 -18
  50. package/template/data/policies/policy-mobile-computing-communications.md +0 -74
  51. package/template/data/training/training-anti-bribery-high-risk-roles.json +0 -16
  52. package/template/data/training/training-anti-bribery-high-risk-roles.md +0 -19
  53. package/template/data/training/training-privileged-sensitive-roles.json +0 -20
  54. package/template/data/training/training-privileged-sensitive-roles.md +0 -20
  55. package/template/data/training/training-secure-development.json +0 -19
  56. package/template/data/training/training-secure-development.md +0 -22
@@ -1,17 +1,31 @@
1
1
  # Policy Instructions
2
2
 
3
- Policies state required behavior. Controls, obligations, training, attestations, and evidence show how the organization applies that behavior.
3
+ 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.
4
+
5
+ FileGRC does not infer technical implementation from Policy prose. Put configuration facts in Controls, Components, Systems, governed schedules, and Evidence.
6
+
7
+ Keep durable mandatory outcomes in Policy prose. Put adjustable values such as retention periods, scan cadence, recovery frequency, and review windows in the linked Control, System, Document schedule, or Obligation. Starter values are proposals: management must confirm or replace each value before it counts as configured.
4
8
 
5
9
  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. The reviewer will usually be another leader or manager in the organization, but may be external.
6
10
 
7
- Keep a policy `draft` until its text, owner, scope, related requirements and controls, approval, effective date, review Obligation, and acknowledgement requirement match actual practice. When activating it:
11
+ 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.
12
+
13
+ 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.
14
+
15
+ Add another Policy only when management expands the program scope or has a distinct approval audience, owner, or legal requirement.
8
16
 
9
- 1. Record the real approver and approval date.
10
- 2. Set the effective date.
11
- 3. Link the controls and requirements it supports.
12
- 4. Update or create its recurring and event obligations.
13
- 5. Assign training or attestations when the policy requires them.
17
+ 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:
14
18
 
15
- The independent policy approver is a management reviewer, not the CPA auditor. Appoint the reviewer during policy adoption. Recurring and event obligations linked to the policy remain proposals until the policy is active and effective and, when they name controls, at least one linked control is implemented.
19
+ 1. Review the per-Policy activation assessment.
20
+ 2. Review linked Controls that are planned or partial, missing Components or evidence sources, missing schedules, and unresolved Exceptions.
21
+ 3. Complete required governed plans and assign Training or Attestations.
22
+ 4. Set the real effective date and change the approved Policy to `active` at implementation cutover.
23
+ 5. If management activates with a known gap, document the decision, follow-up, and any time-bound Exception. Activation does not mark a Control implemented, and Evidence Readiness still requires active and operating Policies.
24
+
25
+ The independent Policy approver is a management reviewer, not the CPA auditor. Appoint the reviewer during Policy approval. Enabled recurring and event Obligations remain dormant until every governing Policy is active and effective and, when they name Controls, at least one linked Control is implemented.
26
+
27
+ If a proposed effective date has passed, choose a current or future activation date. Never backdate adoption.
16
28
 
17
29
  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.
30
+
31
+ 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.
@@ -10,18 +10,11 @@
10
10
  "version": "1.0",
11
11
  "audience": [
12
12
  "employees",
13
- "contractors",
14
- "vendors"
13
+ "contractors"
15
14
  ],
16
15
  "acknowledgementRequired": true,
17
- "relatedPolicyIds": [
18
- "policy-clear-desk-screen",
19
- "policy-data-protection-handling",
20
- "policy-mobile-computing-communications"
21
- ],
22
16
  "relatedDocumentIds": [
23
- "document-business-continuity-disaster-recovery",
24
- "document-incident-response-plan",
17
+ "document-security-incident-recovery-plan",
25
18
  "document-data-retention-schedule"
26
19
  ],
27
20
  "proposedEffectiveOn": "{{effective_date}}",
@@ -1,233 +1,290 @@
1
1
  # Information Security Policy
2
2
 
3
- ## Purpose
3
+ ## Purpose and scope
4
4
 
5
- This policy defines the information security program for {{company_name}}. Its goals are to protect the confidentiality, integrity, and availability of company and customer information and to support reliable operation of in-scope services.
5
+ 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.
6
6
 
7
- ## Scope
7
+ 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.
8
8
 
9
- This policy applies to:
9
+ 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.
10
10
 
11
- - Employees, contractors, vendors, and other authorized users
12
- - Company-managed and personally owned devices used for company work
13
- - Applications, infrastructure, repositories, networks, data, and business processes managed by or for {{company_name}}
14
- - Vendors that store, process, transmit, secure, or recover company or customer data
11
+ ## Consolidated policy index
15
12
 
16
- More specific standards and procedures may set stricter requirements.
13
+ - **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.
14
+ - **Assets, data, and access:** Asset Management; Data Classification, Handling, and Protection; Access Control; Identification, Authentication, and Password.
15
+ - **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.
16
+ - **Engineering and security operations:** Secure Development and Change Management; Vulnerability, Patch, and Penetration Testing; Logging, Monitoring, and Audit Trail; Incident Response.
17
+ - **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.
17
18
 
18
- ## Governance and responsibilities
19
+ ## Definitions
19
20
 
20
- The current Policy Owner owns the information security program and this policy. Questions and incident reports should be sent to {{security_contact_email}}.
21
+ - **Worker:** An employee or contractor.
22
+ - **System:** An application, service, process, or infrastructure used to store or process information or support an in-scope service.
23
+ - **Component:** A technology, process, facility, or provider-supplied element within or supporting a System.
24
+ - **Control:** An administrative, technical, or physical safeguard.
25
+ - **Evidence:** Retained information that supports a security fact, decision, or activity.
26
+ - **Vendor:** An external party that provides a product or service.
27
+ - **Exception:** A management-approved, time-bound departure from a requirement.
28
+ - **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.
29
+ - **Approved:** Authorized by the accountable owner or management under the applicable governance process.
21
30
 
22
- The policy owner:
31
+ These definitions set the minimum scope. Management may classify additional assets as important based on risk.
23
32
 
24
- - Maintains security policies, risks, controls, and improvement plans.
25
- - Reports material security matters to company leadership.
26
- - Coordinates incidents, exercises, reviews, and audit work.
27
- - Approves security exceptions or obtains the required approval.
33
+ ## Information Security Governance and Organization Policy
28
34
 
29
- An independent reviewer chairs the security and risk oversight group. This person must be separate from the policy owner and able to challenge the owner's decisions. The reviewer will usually be another leader or manager in the organization, but may be external. The reviewer approves policies and governed plans, challenges management's assessment of control operation, and records independent decisions.
35
+ ### Roles and oversight
30
36
 
31
- The security and risk oversight group meets at least quarterly to review the risk register, material incidents, significant findings, vendor and access review results, policy changes, exercises, and overdue work. Each meeting has formal minutes, decisions, and assigned actions. When no suitable internal independent reviewer is available, the organization appoints a qualified external person to fill the role.
37
+ - **Policy Owner:** Maintains this Policy, the risk program, Controls, approved supporting plans, Exceptions, and improvement work.
38
+ - **System and process owners:** Approve access, maintain safeguards, keep inventories and recovery facts current, and resolve findings.
39
+ - **Independent reviewer:** Remains separate from the Policy Owner, approves the Policy, and challenges management's assessment of Control operation.
32
40
 
33
- System and process owners classify their systems and data, approve access, maintain safeguards, respond to findings, and keep recovery information current.
41
+ ### Program review
34
42
 
35
- Managers ensure that workers complete required onboarding, training, access changes, offboarding, and a documented performance review at least annually. Every user must follow policy, protect credentials and devices, and report suspected security events.
43
+ 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.
36
44
 
37
- ## Risk management
45
+ ### Information and communication
38
46
 
39
- {{company_name}} performs an information security risk assessment at least annually and after a material change that could alter risk. The assessment identifies threats, affected assets and obligations, existing controls, likelihood, impact, treatment, owners, and target dates.
47
+ 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.
40
48
 
41
- Risks are tracked until they are mitigated, transferred, avoided, or accepted by a person with suitable authority. Accepted risks need a reason, approval, and review date. High and critical risks are reviewed at least quarterly.
49
+ ### Conduct and reporting
42
50
 
43
- ## Asset and system management
51
+ 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.
44
52
 
45
- {{company_name}} maintains inventories of important systems, devices, software, service accounts, vendors, and data stores. Each item has an owner and, when relevant, a criticality, data classification, lifecycle status, and recovery objective.
53
+ 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.
46
54
 
47
- Owners must approve new systems before they process Confidential or Restricted data. Unsupported or unneeded assets must be upgraded, isolated, or retired.
55
+ ## Risk Management and Compliance Policy
48
56
 
49
- Company data and software must be removed from retired devices through an approved process. Disposal records must identify the asset, method, date, and responsible person.
57
+ ### Obligations and risk assessment
50
58
 
51
- ## Workforce security
59
+ 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.
52
60
 
53
- Where lawful and appropriate to the role, {{company_name}} may perform background checks before granting sensitive access. Workers must agree to applicable confidentiality, acceptable-use, and intellectual-property terms.
61
+ 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.
54
62
 
55
- Workers complete security training within 30 days of starting and at least annually. People with privileged access or security, engineering, finance, privacy, or people-operations duties complete applicable role-based training within 30 days of starting those duties or changing roles. The onboarding or role-change checklist records the assigned training or why a module does not apply.
63
+ ### Control design and review
56
64
 
57
- Managers notify access administrators promptly of role changes and departures. Access for an involuntary or high-risk departure must be removed at or before notification. All other departing-worker access must be removed within 24 hours after employment or services end. Company property and active credentials must be recovered or disabled.
65
+ 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.
58
66
 
59
- ## Identity and access control
67
+ ## Personnel and Human Resources Security Policy
60
68
 
61
- Access is based on business need and least privilege.
69
+ ### Responsibilities and screening
62
70
 
63
- - Each user receives a unique identity. Shared accounts are prohibited unless a documented technical need, named owner, access control, and logging make them necessary.
64
- - Multi-factor authentication is required for administrative access, source control, production systems, email, identity systems, and systems containing Confidential or Restricted data when the system supports it.
65
- - Passwords must be unique, stored in an approved password manager, and never shared in plaintext.
66
- - Systems must enforce approved password, authentication, and lockout settings appropriate to their risk and technical capability.
67
- - Only authorized administrators may change password or lockout settings.
68
- - Default credentials must be changed or disabled before use.
69
- - Privileged access must use separate administrative roles or accounts where practical.
70
- - Access requests and material changes require approval from the manager or system owner.
71
- - Owners review privileged and production access at least quarterly and other important access at least annually.
72
- - Dormant, expired, or unneeded access must be removed.
71
+ 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.
73
72
 
74
- Service accounts require a named owner, stated purpose, minimum permissions, and protected credentials. Secrets must not be committed to source control.
73
+ ### Workforce lifecycle
75
74
 
76
- ## Data protection
75
+ 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.
77
76
 
78
- The Data Protection and Handling Policy defines classification, approved use, sharing, retention, and disposal. At a minimum:
77
+ ### Competence review
79
78
 
80
- - Collect and retain only data needed for an approved purpose.
81
- - Encrypt Confidential and Restricted data in transit over untrusted networks.
82
- - Encrypt Confidential and Restricted data at rest in approved systems and on devices.
83
- - Keep production data out of development and test systems unless approved and equally protected.
84
- - Restrict data exports and public links.
85
- - Store credentials and cryptographic keys in approved protected systems.
79
+ 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.
86
80
 
87
- ## Endpoint and mobile security
81
+ ## Security Awareness and Training Policy
88
82
 
89
- Devices used for company work must:
83
+ 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.
90
84
 
91
- - Run a supported operating system and current security software.
92
- - Use full-disk encryption when supported.
93
- - Lock automatically after no more than 15 minutes of inactivity.
94
- - Require authentication after locking or restarting.
95
- - Install security updates within the vulnerability-remediation targets in this policy unless an approved exception applies.
96
- - Use malware protection and host firewall controls appropriate to the platform.
97
- - Permit remote lock or wipe when company-managed and supported.
85
+ 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.
98
86
 
99
- Lost, stolen, compromised, or unexpectedly reconfigured devices must be reported immediately. The Mobile Computing and Communications Policy defines additional requirements.
87
+ ## Acceptable Use, Clear Desk, and Clear Screen Policy
100
88
 
101
- Malware protection must run continuous protection where the platform supports it and a full or equivalent periodic scan at least monthly.
89
+ Users must:
102
90
 
103
- ## Network and infrastructure security
91
+ - Use approved identities, devices, applications, storage, messaging, meeting, and transfer services.
92
+ - Protect credentials, authentication devices, company equipment, customer information, and security records.
93
+ - Keep company data out of personal accounts and unapproved applications.
94
+ - Lock unattended devices and protect papers, screens, conversations, and remote meetings from unauthorized access.
95
+ - Keep Confidential and Restricted information from unattended work areas and dispose of it through approved methods.
96
+ - Report lost, stolen, compromised, or unexpectedly reconfigured devices promptly.
97
+ - Return company property and stop using company access when employment, services, or business need ends.
104
98
 
105
- Owners must:
99
+ 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.
106
100
 
107
- - Limit inbound and outbound connectivity to approved business needs.
108
- - Separate production from development, test, and general user environments where practical.
109
- - Use encrypted administrative protocols and restrict management interfaces.
110
- - Review firewall rules and other material network access at least annually.
111
- - Disable unused services, ports, accounts, and default configurations.
112
- - Protect cloud and infrastructure management interfaces with multi-factor authentication.
113
- - Record infrastructure configuration in reviewed code or another controlled system where practical.
101
+ ## Asset Management Policy
114
102
 
115
- Important systems use documented secure configuration baselines. Owners review deviations, remove unnecessary defaults, and track approved exceptions. A material change to system behavior, security, availability, or customer commitments must include an appropriate communication plan.
103
+ {{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.
116
104
 
117
- Wireless networks used for company work must use current encryption and authentication. Public or untrusted networks require an approved protected connection.
105
+ 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.
118
106
 
119
- Remote production access is limited to approved users, requires multi-factor authentication, and must originate from a trusted network or use an approved encrypted connection. Users on public or otherwise untrusted networks must use the additional safeguards approved for remote access.
107
+ ## Data Classification, Handling, and Protection Policy
120
108
 
121
- ## Secure development and change management
109
+ ### Classification and minimization
122
110
 
123
- Software and infrastructure changes must be recorded, reviewed, tested, approved, and recoverable in proportion to risk. The record should identify the reason, author, reviewer, test result, deployment, and rollback method.
111
+ 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.
124
112
 
125
- Production changes should be made through an approved deployment process. Emergency changes may use an expedited review, but they must be documented and reviewed after service is stable.
113
+ ### Handling and transfer
126
114
 
127
- Development practices include:
115
+ 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.
128
116
 
129
- - Peer review for material code and infrastructure changes
130
- - Automated or manual security tests suited to the change
131
- - Separation of production duties where practical
132
- - Protected branches and controlled deployment credentials
133
- - Dependency and secret scanning where supported
134
- - No production secrets in source code, test fixtures, or logs
135
- - Validation of input and authorization at trust boundaries
117
+ ### Media, retention, and disposal
136
118
 
137
- ## Vulnerability and patch management
119
+ 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.
138
120
 
139
- {{company_name}} monitors trusted sources for vulnerabilities affecting in-scope systems. It scans internet-facing and production systems at least quarterly and after a material change when practical. An independent penetration test is performed at least annually for the external attack surface of the in-scope service.
121
+ 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.
140
122
 
141
- The security owner assigns the final severity using a recognized technical scoring method together with exploit availability, reachability, affected privileges, data classification, exposure, and business impact. The remediation clock starts when {{company_name}} confirms the finding and assigns an owner. A later severity change must record the reason and date.
123
+ ## Cryptography, Encryption, Key, and Secrets Management Policy
142
124
 
143
- Confirmed vulnerabilities are assigned a target based on their final severity:
125
+ ### Encryption requirements
144
126
 
145
- | Severity | Target remediation time |
146
- | --- | --- |
147
- | Critical | 7 days |
148
- | High | 14 days |
149
- | Medium | 30 days |
150
- | Low | 90 days |
127
+ 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.
151
128
 
152
- If remediation cannot meet the target, the owner must document the reason, exposure, compensating controls, revised date, and risk approval.
129
+ ### Key and secret management
153
130
 
154
- ## Logging and monitoring
131
+ Encryption keys and other secrets require:
155
132
 
156
- Important systems must record security-relevant activity needed to investigate misuse and support operations. Depending on the system, this includes:
133
+ - **Ownership and access:** Named ownership and least-privilege access.
134
+ - **Generation and storage:** Protected generation and storage.
135
+ - **Distribution and use:** Controlled distribution and use.
136
+ - **Rotation and revocation:** Rotation or replacement based on risk and events, and revocation when access or trust ends.
137
+ - **Recovery:** Recoverability when loss would prevent an approved business or recovery process.
157
138
 
158
- - Authentication success and failure
159
- - Privileged and administrative actions
160
- - Access-control and identity changes
161
- - Production deployments and configuration changes
162
- - Access to Restricted data
163
- - Security control failures and alerts
139
+ 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.
164
140
 
165
- Logs must use synchronized time, restrict alteration and access, and avoid unnecessary secrets or personal data. Security logs for important systems are retained for at least 12 months unless a longer contractual or legal period applies.
141
+ ## Access Control Policy
166
142
 
167
- Owners review or alert on events based on risk. Alerts must have an assigned response path. The annual incident response exercise tests at least one representative alert from generation through acknowledgement, escalation, and fallback. A material change to an alert or response path receives an appropriate test within 30 days, or the owner records why no test applies.
143
+ ### Access lifecycle
168
144
 
169
- Owners review important log output and access to logs at least quarterly. They also monitor process health, network use, processor load, memory use, disk capacity, and other indicators needed to detect service degradation. Important systems have documented alert thresholds and response ownership.
145
+ 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.
170
146
 
171
- ## Incident response
147
+ ### Privileged, shared, and service accounts
172
148
 
173
- Anyone who suspects unauthorized access, malware, data loss, credential exposure, security-control failure, or other security harm must report it immediately to {{security_contact_email}}.
149
+ - **Privileged access:** Limited to approved duties and uses separate administrative identities or roles where technically supported and appropriate to risk.
150
+ - **Shared accounts:** Require a documented technical need, named owner, restricted use, protected credentials, and logging.
151
+ - **Service accounts:** Require a named owner, approved purpose, minimum permissions, protected credentials, lifecycle dates or review, and monitoring appropriate to risk.
174
152
 
175
- The Incident Response Plan defines severity, materiality, declaration, roles, escalation, evidence handling, notification assessment, recovery, and closure. The incident lead will:
153
+ ## Identification, Authentication, and Password Policy
176
154
 
177
- 1. Record and assess the report.
178
- 2. Contain the event and preserve evidence.
179
- 3. Remove the cause and recover affected service.
180
- 4. Coordinate legal, contractual, privacy, insurance, customer, and regulatory review.
181
- 5. Communicate through authorized channels.
182
- 6. Document the outcome, lessons, and follow-up work.
155
+ ### Authentication and passwords
183
156
 
184
- The incident lead assigns a severity based on actual or likely harm. High-severity incidents receive immediate leadership and technical escalation, frequent status updates, and review of external notification duties. Lower-severity events still receive an owner, documented resolution, and escalation if impact grows.
157
+ 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.
185
158
 
186
- {{company_name}} tests its incident process and a representative alert path at least annually. Material incidents receive a retrospective within one week and tracked corrective actions.
159
+ 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.
187
160
 
188
- ## Business continuity, backup, and recovery
161
+ ### Multi-factor authentication
189
162
 
190
- Important systems have recovery objectives based on business impact. Unless a system has an approved objective that requires stronger safeguards, important production data is backed up at least daily and retained for at least 30 days. Backups must restrict access, report failures, and be restored in a test at least annually.
163
+ - **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.
164
+ - **Customer and external-user access:** MFA is required when an approved Control, customer commitment, or risk decision requires it.
165
+ - **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.
191
166
 
192
- The Business Continuity and Disaster Recovery Plan defines activation, response, communication, and recovery duties. Continuity and recovery exercises are recorded with results and follow-up work.
167
+ ## Endpoint, Mobile Device, BYOD, and Malware Protection Policy
193
168
 
194
- ## Vendor security
169
+ ### Company devices and platform protection
195
170
 
196
- Vendors receive access only after an appropriate security and privacy review. The review considers the service, data, access, availability needs, incident history, independent assurance, recovery capability, and contract terms.
171
+ 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.
197
172
 
198
- Contracts with vendors that handle Confidential or Restricted data should address:
173
+ 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.
199
174
 
200
- - Permitted data use and confidentiality
201
- - Security safeguards
202
- - Incident notification
203
- - Subprocessor controls
204
- - Service continuity
205
- - Data return and deletion
206
- - Audit or assurance rights when warranted
175
+ ### Personal devices
207
176
 
208
- Critical and high-risk vendors are reviewed at least annually. A material service change, data-use change, or vendor incident triggers a reassessment within 30 days. The owner updates the vendor, risk, contract, data-use, and follow-up records affected by the reassessment.
177
+ 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.
209
178
 
210
- ## Physical security
179
+ ## Remote Access and Remote Work Policy
211
180
 
212
- Company facilities and equipment must be protected according to their risk. Access to nonpublic work areas is limited to authorized people. Visitors must be controlled and accompanied where sensitive work or information is present.
181
+ 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.
213
182
 
214
- Remote workers must follow the Clear Desk and Clear Screen Policy and protect devices and conversations from unauthorized viewing or access.
183
+ 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.
215
184
 
216
- ## Compliance, exceptions, and enforcement
185
+ ## Physical and Environmental Security Policy
217
186
 
218
- {{company_name}} identifies security, privacy, contractual, and regulatory obligations that apply to its work and maps them to responsible controls. Evidence should be retained according to the applicable audit and record-retention period.
187
+ 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.
219
188
 
220
- An exception to this policy requires:
189
+ 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.
221
190
 
222
- - A specific scope and business reason
223
- - A risk assessment
224
- - Compensating controls
225
- - An accountable owner
226
- - An expiration or review date
227
- - Approval from the current Policy Owner or a person with greater authority
191
+ ## Network and Communications Security Policy
228
192
 
229
- Violations may result in access removal, corrective action, contract remedies, or other action allowed by law and agreement.
193
+ 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.
230
194
 
231
- ## Review
195
+ 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.
232
196
 
233
- The policy owner reviews this policy at least annually and after a material change to systems, services, risks, or obligations. An independent reviewer who is separate from the policy owner approves this policy and other governed policies and plans. The reviewer may be internal or external. The security and risk oversight group reviews material changes and records its decision in meeting minutes. Git history records approvals and changes.
197
+ ## Configuration Management and System Maintenance Policy
198
+
199
+ 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.
200
+
201
+ 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.
202
+
203
+ ## Secure Development and Change Management Policy
204
+
205
+ ### Change control
206
+
207
+ 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.
208
+
209
+ ### Security design and development safeguards
210
+
211
+ 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.
212
+
213
+ ## Vulnerability, Patch, and Penetration Testing Policy
214
+
215
+ ### Vulnerability and patch management
216
+
217
+ {{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.
218
+
219
+ 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.
220
+
221
+ ### Penetration testing
222
+
223
+ 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.
224
+
225
+ ## Logging, Monitoring, and Audit Trail Policy
226
+
227
+ ### Logging and audit trails
228
+
229
+ 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.
230
+
231
+ 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.
232
+
233
+ ### Monitoring and alert testing
234
+
235
+ 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.
236
+
237
+ ## Incident Response Policy
238
+
239
+ 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.
240
+
241
+ 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.
242
+
243
+ ## Business Continuity and Disaster Recovery Policy
244
+
245
+ 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.
246
+
247
+ 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.
248
+
249
+ ## Backup and Restoration Policy
250
+
251
+ 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.
252
+
253
+ 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.
254
+
255
+ ## Vendor, Third-Party, and Supply Chain Risk Management Policy
256
+
257
+ ### Due diligence
258
+
259
+ 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.
260
+
261
+ ### Contract safeguards
262
+
263
+ When applicable to the service and risk, contracts address:
264
+
265
+ - Permitted use and confidentiality.
266
+ - Security responsibilities and incident notice.
267
+ - Access and subprocessor restrictions.
268
+ - Continuity and data return or deletion.
269
+ - Termination.
270
+ - Assurance or audit rights.
271
+
272
+ Management does not require every term for every Vendor, but records omissions that create material risk or conflict with an approved commitment.
273
+
274
+ ### Existing Vendors and ongoing monitoring
275
+
276
+ 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.
277
+
278
+ ## Exceptions, Compliance, Enforcement, and Policy Review
279
+
280
+ ### Exceptions and enforcement
281
+
282
+ 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.
283
+
284
+ ### Policy review
285
+
286
+ 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.
287
+
288
+ ### Representations
289
+
290
+ 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.
@@ -13,10 +13,7 @@
13
13
  "assignmentTrigger": "onboarding",
14
14
  "completionWindowDays": 30,
15
15
  "policyIds": [
16
- "policy-clear-desk-screen",
17
- "policy-data-protection-handling",
18
- "policy-information-security",
19
- "policy-mobile-computing-communications"
16
+ "policy-information-security"
20
17
  ],
21
18
  "controlIds": [
22
19
  "control-security-communication",