Correct prompt for common controls, update controls schema, fix broke…

…n links. (finos#499)
dogle-scottlogic · Nov 20, 2024 · 2ac6d3a · 2ac6d3a
1 parent 954ca8f
commit 2ac6d3a
Show file tree

Hide file tree

Showing 30 changed files with 174 additions and 74 deletions.
diff --git a/.github/CODEOWNERS b/.github/CODEOWNERS
@@ -24,7 +24,7 @@
 ########
 #
 # Community Guidelines only need review from the Community Structure WG
-/docs/governance/community-guidelines @finos/ccc-wg-community-structure
+/docs/community-guidelines @finos/ccc-wg-community-structure
 #
 ########
 

diff --git a/.vscode/common-controls.code-snippets b/.vscode/common-controls.code-snippets
@@ -1,63 +1,63 @@
 {
     "Prevent unencrypted requests": {
       "scope": "yaml",
-      "prefix": "CT1, CT Prevent unencrypted requests",
+      "prefix": "CC1, CC Prevent unencrypted requests",
       "body": [
         "- CCC.C01 # Prevent unencrypted requests control"
       ],
       "description": "Common Control Prevent unencrypted requests"
     },
     "Ensure data encryption at rest": {
       "scope": "yaml",
-      "prefix": "CT2, CT Ensure data encryption at rest",
+      "prefix": "CC2, CC Ensure data encryption at rest",
       "body": [
         "- CCC.C02 # Ensure data encryption at rest for all stored data"
       ],
       "description": "Common Control Ensure data encryption at rest"
     },
     "Implement multi-factor authentication": {
       "scope": "yaml",
-      "prefix": "CT3, CT Implement MFA for access",
+      "prefix": "CC3, CC Implement MFA for access",
       "body": [
         "- CCC.C03 # Implement multi-factor authentication (MFA) for access"
       ],
       "description": "Common Control Implement multi-factor authentication (MFA) for access"
     },
     "Log all access and changes": {
       "scope": "yaml",
-      "prefix": "CT4, CT Log all access and changes",
+      "prefix": "CC4, CC Log all access and changes",
       "body": [
         "- CCC.C04 # Log all access and changes"
       ],
       "description": "Common Control Log all access and changes"
     },
     "Prevent access from untrusted entities": {
       "scope": "yaml",
-      "prefix": "CT5, CT Prevent access from untrusted entities",
+      "prefix": "CC5, CC Prevent access from untrusted entities",
       "body": [
         "- CCC.C05 # Prevent access from untrusted entities"
       ],
       "description": "Common Control Prevent access from untrusted entities control"
     },
     "Prevent deployment in restricted regions": {
       "scope": "yaml",
-      "prefix": "CT6, CT Prevent deployment in restricted regions",
+      "prefix": "CC6, CC Prevent deployment in restricted regions",
       "body": [
         "- CCC.C06 # Prevent deployment in restricted regions"
       ],
       "description": "Common Control Prevent deployment in restricted regions"
     },
     "Alert on non-human enumeration": {
       "scope": "yaml",
-      "prefix": "CT7, CT Alert on non-human enumeration",
+      "prefix": "CC7, CC Alert on non-human enumeration",
       "body": [
         "- CCC.C07 # Alert on non-human enumeration"
       ],
       "description": "Common Control Alert on non-human enumeration"
     },
     "Enable multi-zone or multi-region data replication": {
       "scope": "yaml",
-      "prefix": "CT8, CT Enable multi-zone or multi-region data replication",
+      "prefix": "CC8, CC Enable multi-zone or multi-region data replication",
       "body": [
         "- CCC.C08 # Enable multi-zone or multi-region data replication"
       ],

diff --git a/README.md b/README.md
@@ -12,7 +12,7 @@ FINOS Common Cloud Controls (FINOS CCC) is an open standard project that describ
 
 This standard is a collaborative project which aims to develop a unified set of cybersecurity, resiliency, and compliance controls for common services across the major cloud service providers (CSPs).
 
-[Download the FINOS CCC Primer Here](./docs/training/FINOS-CCC-Primer-June-2024.pdf)
+[Download the FINOS CCC Primer Here](./docs/resources/training/FINOS-CCC-Primer-June-2024.pdf)
 
 ## What Are The Benefits?
 

diff --git a/docs/community-guidelines/README.md b/docs/community-guidelines/README.md
@@ -17,6 +17,6 @@ In order for a guideline to become a policy a [SC], they must be put forward for
 2. The [SC] sponsor should call a [SC] [vote] and if approved by the majority the PR can be merged and the recommendation is now a policy.
 
 [Policies]: ../community-policies
-[vote]: ../steering/charter.md#voting
-[SC]: ../community-groups.md#steering-committee
-[WG]: ../community-groups.md#working-groups
+[vote]: ../governance/steering/charter.md#voting
+[SC]: ../governance/community-structure.md#steering-committee
+[WG]: ../governance/community-structure.md#working-groups
diff --git a/docs/community-guidelines/communication.md b/docs/community-guidelines/communication.md
@@ -36,7 +36,7 @@ Any meeting published on the public calendar must additionally adhere to a stric
 - If these meetings are hosted by FINOS they must follow the guidance for [FINOS hosted meetings](#finos-hosted-meetings).
 - If these meetings are NOT hosted by FINOS then any noteworthy decisions or outcomes should be communicated back to the wider [WG] via the mailing list.
 
-[SC]: ../community-groups.md#steering-committee
-[WG]: ../community-groups.md#working-groups
+[SC]: ../governance/community-structure.md#steering-committee
+[WG]: ../governance/community-structure.md#working-groups
 [community guideline]: ./README.md
-[FINOS Point of Contact]: ../finos-poc.md
+[FINOS Point of Contact]: ../governance/finos-poc.md
diff --git a/docs/community-guidelines/content-standards-and-practices/README.md b/docs/community-guidelines/content-standards-and-practices/README.md
@@ -27,6 +27,6 @@ This directory will contain the content development standards and practices, whe
 
 Feedback on these policies is vital for continuous improvement. If you have suggestions or updates, please communicate this to the [Delivery WG]. Do note that new policies and standards may be created or modified by a [vote] of the [SC] at any time, following the same process as [Upgrading a Recommendation to become a Policy](../../community-guidelines/README.md#upgrading-a-recommendation-to-become-a-policy).
 
-[SC]: ../../community-groups.md#steering-committee
-[vote]: ../../steering/charter.md#voting
-[Delivery WG]: ../../working-groups/delivery
+[SC]: ../../governance/community-structure.md#steering-committee
+[vote]: ../../governance/steering/charter.md#voting
+[Delivery WG]: ../../governance/working-groups/delivery/charter.md
diff --git a/docs/community-guidelines/content-standards-and-practices/control-definitions.md b/docs/community-guidelines/content-standards-and-practices/control-definitions.md
@@ -30,7 +30,7 @@ When creating or updating a `controls.yaml` file for a service category, follow
 
 ## Control Definition Format
 
-To maintain consistency, all controls— whether common or specific— must follow the same format, style, and tone. Each control should adhere to the [control template](../templates/controls.yaml) before release.
+To maintain consistency, all controls— whether common or specific— must follow the same format, style, and tone. Each control should adhere to the [control template](../../resources/templates/controls.yaml) before release.
 
 ### Control Definition Values
 

diff --git a/docs/community-guidelines/content-standards-and-practices/feature-definitions.md b/docs/community-guidelines/content-standards-and-practices/feature-definitions.md
@@ -30,7 +30,7 @@ When creating or updating a `features.yaml` file for a service category, follow
 
 ## Feature Definition Format
 
-To maintain consistency, all features—whether common or specific—must follow the same format, style, and tone. Each feature should adhere to the [feature template](../templates/features.yaml) before release.
+To maintain consistency, all features—whether common or specific—must follow the same format, style, and tone. Each feature should adhere to the [feature template](../../resources/templates/features.yaml) before release.
 
 ### Feature Definition Values
 
@@ -46,5 +46,5 @@ When creating a new feature definition, use the following values:
 Although a review from the [Communications WG] is optional, it may be useful if additional support is needed to match the writing style or tone of the document.
 
 [common features]: /services/common-features.yaml
-[Communications WG]: ../../working-groups/communications/charter.md
+[Communications WG]: ../../governance/working-groups/communications/charter.md
 [delivery tooling]: /delivery-tooling
diff --git a/...ty-guidelines/content-standards-and-practices/markdown/formatting-guidelines.md b/...ty-guidelines/content-standards-and-practices/markdown/formatting-guidelines.md
@@ -36,4 +36,4 @@ This section of this document contains a list of rules that are enabled for this
 
 Adhering to these formatting guidelines and using `prettier` will help ensure that our Markdown documents are not only consistent but also maintain a high standard of quality and readability. Regular use of `prettier` will streamline the document creation process, making it easier for everyone to produce well-formatted documentation.
 
-[WG]: ../../../community-groups.md#working-groups
+[WG]: ../../../governance/community-structure.md#working-groups
diff --git a/...unity-guidelines/content-standards-and-practices/markdown/linting-guidelines.md b/...unity-guidelines/content-standards-and-practices/markdown/linting-guidelines.md
@@ -73,4 +73,4 @@ This section of this document contains a list of rules that are enabled for this
 
 Following these Markdown linting guidelines will help maintain a standard style across all our documents. Consistent formatting not only improves readability but also creates a professional appearance for all our communications. We encourage all contributors to adhere to these practices to ensure clarity and uniformity in our documentation.
 
-[WG]: ../../../community-groups.md#working-groups
+[WG]: ../../../governance/community-structure.md#working-groups
diff --git a/docs/community-guidelines/content-standards-and-practices/release-assets.md b/docs/community-guidelines/content-standards-and-practices/release-assets.md
@@ -73,7 +73,7 @@ release_details:
       - "PR#34: Updated controls for increased encryption requirements."
 ```
 
-[release]: ../releases.md
+[release]: ../releases/README.md
 [features]: ./feature-definitions.md
 [threats]: ./threat-definitions.md
 [controls]: ./control-definitions.md
diff --git a/docs/community-guidelines/content-standards-and-practices/threat-definitions.md b/docs/community-guidelines/content-standards-and-practices/threat-definitions.md
@@ -50,6 +50,6 @@ Although a review from the [Communications WG] is optional, it may be useful if
 This structure ensures that threats are standardized and can be consistently identified and addressed across all services within the CCC Taxonomy.
 
 [common threats]: /services/common-threats.yaml
-[Communications WG]: ../../working-groups/communications/charter.md
+[Communications WG]: ../../governance/working-groups/communications/charter.md
 [delivery tooling]: /delivery-tooling
-[threats template]: ../templates/threats.yaml
+[threats template]: ../../resources/templates/threats.yaml
diff --git a/docs/community-guidelines/meetings.md b/docs/community-guidelines/meetings.md
@@ -51,6 +51,6 @@ Once minutes are added to the GitHub issue, close the issue.
 
 In the event that a meeting needs to be cancelled then the [FINOS Point of Contact] should be notified as soon as possible. The cancellation should also be communicated via the mailing list for the [WG].
 
-[WG]: ../community-groups.md#working-groups
-[FINOS Point of Contact]: ../finos-poc.md
+[WG]: ../governance/community-structure.md#working-groups
+[FINOS Point of Contact]: ../governance/finos-poc.md
 [community guideline]: ./README.md
diff --git a/docs/community-guidelines/member-roles.md b/docs/community-guidelines/member-roles.md
@@ -144,6 +144,6 @@ Specific group charters may specify a shorter period for their roles.
 [Linux Foundation Code of Conduct]: https://events.linuxfoundation.org/about/code-of-conduct/
 [CODEOWNERS]: https://github.com/finos/common-cloud-controls/blob/main/.github/CODEOWNERS
 [community mail group]: mailto:[email protected]
-[community groups]: ../community-groups.md
-[SC]: ../community-groups.md#steering-committee
-[WG]: ../community-groups.md#working-groups
+[community groups]: ../governance/community-structure.md
+[SC]: ../governance/community-structure.md#steering-committee
+[WG]: ../governance/community-structure.md#working-groups
diff --git a/docs/community-guidelines/proposing-working-group.md b/docs/community-guidelines/proposing-working-group.md
@@ -2,13 +2,13 @@
 
 To propose a new working group complete the items in the check list below:
 
-- Create a PR with a draft charter which follows this [template](./templates/charter.md).
+- Create a PR with a draft charter which follows this [template](../resources/templates/charter.md).
 - Find a [SC] member to sponsor the [WG].
 - The proposal must include the name of the [WG] Lead.
 - The [SC] sponsor will call for a [vote] on the new [WG] when it is ready.
 - If the proposal receives a majority [vote], it is immediately considered active and responsible to act according to its charter.
 - After the [SC] has approved the [WG], the sponsor should promptly request a mailing list for the [WG] by contacting <[email protected]>. The mailing list should use the naming convention `ccc-[wg-name]@lists.finos.org`.
 
-[WG]: ../community-groups.md#working-groups
-[SC]: ../community-groups.md#steering-committee
-[vote]: ../steering/charter.md#voting
+[WG]: ../governance/community-structure.md#working-groups
+[SC]: ../governance/community-structure.md#steering-committee
+[vote]: ../governance/steering/charter.md#voting
diff --git a/...e/community-guidelines/releases/README.md → docs/community-guidelines/releases/README.md b/...e/community-guidelines/releases/README.md → docs/community-guidelines/releases/README.md
@@ -66,10 +66,10 @@ The release process involves contributors proposing changes through a pull reque
 1. **Publishing:** The Release Manager creates the official release based on the final approved release candidate. This is published on GitHub along with release notes and documentation updates.
 2. **Announcement:** The [Communications WG] announces the release through appropriate channels suchs as mailing lists and social media.
 
-[WG]: ../../community-groups.md#working-groups
-[Security WG]: ../../working-groups/security/charter.md
-[Taxonomy WG]: ../../working-groups/taxonomy/charter.md
-[Delivery WG]: ../../working-groups/delivery/charter.md
+[WG]: ../../governance/community-structure.md#working-groups
+[Security WG]: ../../governance/working-groups/security/charter.md
+[Taxonomy WG]: ../../governance/working-groups/taxonomy/charter.md
+[Delivery WG]: ../../governance/working-groups/delivery/charter.md
 [Change Management Board]: ./cmb.md
-[Communications WG]: ../../working-groups/communications/charter.md
+[Communications WG]: ../../governance/working-groups/communications/charter.md
 [community guideline]: ../README.md
diff --git a/docs/community-guidelines/releases/cmb.md b/docs/community-guidelines/releases/cmb.md
@@ -0,0 +1,100 @@
+# Change Management Board
+
+This document is a [community guideline].
+
+## Purpose
+
+The document outlines and defines the guidelines for the Change Management Board (CMB) for the Common Cloud Controls (CCC) project.
+
+The CMB is a body of representatives from financial institutions of varying sizes and types. Its primary role is to review and approve changes and new catalogs that are within the Release Candidate. The CMB collectively represents end-user stakeholders, ensuring that each artifact is adaptable to the needs of a wide range of institutions while maintaining consistency and integrity across the board.
+
+## Process
+
+The process followed by the CMB to manage changes includes:
+
+1. **Proposal Submission**
+   - Proposed changes are submitted for CMB review by contributors or working groups within the CCC project.
+1. **Review Cycle**
+   - The CMB reviews the changes based on the established guidelines and feedback from relevant working groups such as the [Security WG], [Delivery WG], and others.
+1. **Approval or Request for Modifications**
+   - After review, the CMB either approves the proposed changes for the next release candidate or requests modifications and additional feedback from the contributor or associated working group.
+1. **Final Approval and Release**
+   - Upon receiving approval, the release manager compiles the final release package, and the CMB confirms the official release of the updated framework.
+
+## Membership
+
+The change management board is composed of a Release Manager and the body of reviewers, both appointed by the [Delivery WG].
+
+A release cycle shall be a minimum of one month, during which time a Release Manager will solicit and arbitrate feedback from the reviewers prior to approving and initiating the release.
+
+### Release Manager Responsibilities
+
+The release manager is not a unilateral authority on the release, rather they are the representative of the group's opinions. Insomuch as they represent the CMB, the release manager holds the final guidance in the lifecycle of an asset.
+
+The release manager will be responsible for the following:
+
+- Collaborate with the CCC working group leads to ensure that the asset is ready for review.
+- Issue an announcement to the CMB, containing:
+  - Links to the asset under review
+  - Desired release date
+  - Deadline for initial responses (two weeks prior to desired release date)
+  - Instructions for participating in this review cycle
+- When a change request (CR) is received:
+  - Evaluate the quality of the CR. If necessary, request adjustments for clarity or conciseness.
+  - Relay the CR to all participating reviewers
+  - At least two members must agree on a CR before it moves forward, with majority opinion ruling when there is dissent.
+  - When discussion has been stabilized for at least 48 hours, determine the status of the CR
+  - If the CR is affirmed by the CMB, create a GitHub issue detailing the CR. Tag and notify the appropriate working group.
+  - If the CR is not affirmed by the CMB, notify the change requestor. The CR should not be resubmitted unless there are substantial changes to the request.
+- When all outstanding requests have been resolved and requested changes have been applied, initiate the release.
+  - Ensure that the release is no sooner than the expected delivery date, and that all actions follow the current processes of the [Delivery WG].
+
+### Reviewer Responsibilities
+
+Members are **not** obligated to review every release but will be notified and may choose to engage in reviews.
+
+When engaging, the following is expected of a CMB member:
+
+- Be thorough, thoughtful, and provide detailed feedback before requesting changes.
+  - Gather feedback from colleagues as needed to support a review.
+- If changes are requested, communicate clearly and promptly through the channels outlined by the Release Manager for the current release cycle.
+  - When a change request (CR) is received, the Release Manager will open discussions and facilitate responses from the board.
+- Members are encouraged to respond within 7 days if they have input on a CR.
+  - The Release Manager logs any dissenting opinions and communicates the majority decision.
+- A release cannot proceed without a minimum of 5 approvals; members are encouraged to help meet this threshold by approving, requesting changes, or contributing to discussion around open change requests.
+
+### Qualifications for Participation
+
+Individuals of any background or experience level may participate in a review.
+
+To approve or request changes, an individual must be an appointed CMB member in good standing.
+
+CMB members are appointed by the [Delivery WG]. If you are interested or have any questions, please reach out to a current [Delivery WG] member or join the community call.
+
+### Release Manager Qualifications
+
+A release manager shall be a [Delivery WG] approver or a CMB member who has provided feedback on a previous release cycle.
+
+Release managers are expected to demonstrate the following qualities:
+
+- Strong written communication skills
+- High attention to detail
+- Commitment to process and protocol
+- Ability to parse and relay complex feedback
+- Fundamental knowledge of the domain featured in the release
+- Reasonable availability and responsiveness during the release cycle (at least one month)
+
+### Breach of Decorum
+
+Members of the Change Management Board are expected to follow the [FINOS Community Code of Conduct](https://community.finos.org/docs/governance/code-of-conduct) at all times.
+
+Appointments shall be permanently revoked in the following cases:
+
+- Repeat disrespectful communication
+- Repeat obstructive behavior such as vague or non-actionable feedback
+- Repeat abandonment of a stated commitment
+- Undermining the process, such as deliberately circumventing or disregarding documented norms
+
+[Security WG]: ../../governance/working-groups/security/charter.md
+[Delivery WG]: ../../governance/working-groups/delivery/charter.md
+[community guideline]: ./README.md
diff --git a/...uidelines/imgs/release-process.drawio.svg → .../releases/imgs/release-process.drawio.svg b/...uidelines/imgs/release-process.drawio.svg → .../releases/imgs/release-process.drawio.svg
diff --git a/docs/community-guidelines/versioning.md b/docs/community-guidelines/versioning.md
@@ -27,7 +27,7 @@ Versioning will be scoped to each artifact delivered by the working groups. This
 
 Releases should happen, at most, one time per month. This schedule ensures a manageable release cadence and maintains the stability of our artifacts. For more information about the releases, please refer to this document: [Releases](./README.md)
 
-[WG]: ../community-groups.md#working-groups
-[Communications WG]: ../working-groups/communications/charter.md
-[Delivery WG]: ../working-groups/delivery/charter.md
+[WG]: ../governance/community-structure.md#working-groups
+[Communications WG]: ../governance/working-groups/communications/charter.md
+[Delivery WG]: ../governance/working-groups/delivery/charter.md
 [community guideline]: ./README.md
diff --git a/docs/community-policies/README.md b/docs/community-policies/README.md
@@ -10,5 +10,5 @@ This directory will contain the latest version of all policies that must be adhe
 
 Policies may be created or modified by a [vote] of the [SC] at any time, following the same process as [Upgrading a Recommendation to become a Policy](../community-guidelines/README.md/#upgrading-a-recommendation-to-become-a-policy).
 
-[SC]: ../community-groups.md#steering-committee
-[vote]: ../steering/charter.md#voting
+[SC]: ../governance/community-structure.md#steering-committee
+[vote]: ../governance/steering/charter.md#voting
Original file line number	Diff line number	Diff line change
Expand Up		@@ -36,4 +36,4 @@ This section of this document contains a list of rules that are enabled for this

		Adhering to these formatting guidelines and using `prettier` will help ensure that our Markdown documents are not only consistent but also maintain a high standard of quality and readability. Regular use of `prettier` will streamline the document creation process, making it easier for everyone to produce well-formatted documentation.

		[WG]: ../../../community-groups.md#working-groups
		[WG]: ../../../governance/community-structure.md#working-groups
Original file line number	Diff line number	Diff line change
Expand Up		@@ -73,4 +73,4 @@ This section of this document contains a list of rules that are enabled for this

		Following these Markdown linting guidelines will help maintain a standard style across all our documents. Consistent formatting not only improves readability but also creates a professional appearance for all our communications. We encourage all contributors to adhere to these practices to ensure clarity and uniformity in our documentation.

		[WG]: ../../../community-groups.md#working-groups
		[WG]: ../../../governance/community-structure.md#working-groups