Update daoip-8.md

DAOIPs/daoip-8.md

@@ -52,7 +52,7 @@ The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL
 
 | Control | Description |
 | :--- | :--- |
-| Data transparency | 1. `[MANDATORY]` The DAO should publish an up to date __governance document__, outlining the steps and stakeholders involved in governance.<br><br> Data transparency is critical to an organization’s security. The governance document should clearly define the person(s) responsible for its upkeep, along with a channel to reach out to them if information is incorrect or outdated. The governance document should include but not limit to the following:<br><br><ul><li>Mandatroy steps in the governance process (temp checks, RFCs, timelines, vote thresholds), type of election (ranked choice, single choice, first past the post, etc).</li><li>Rules of elections, and elected position descriptions and contact information.</li></ul> Along with key details on governance design, and operational rules, the governance document __SHOULD__ include information on all *__privileged roles__* (details on who can do what). Privileged roles should include information pertaining to the powers delegated to said role and identify the addresses associated with each role. For example, can anyone create a new proposal, can proposals be vetoed, are proposal executions autonomous, etc?<br><br>In addition to the governance process, all official service providers and their respective responsibilities should be detailed along with contact information for each team. <br><br>2. `[RECOMMENDED]` The DAO should maintain a repository of all DAO-related artifacts.<br><br> DAO-related artifacts include (but are not limited to) grant programs; list of all smart contracts; list of functional committees, councils and multisigs; trusted service providers; and financial reporting. We recommend using the EIP-4824 standard to facilitate this, as it allows decentralized control of data by the DAO.|
+| Data transparency | 1. `[MANDATORY]` The DAO should publish an up to date __resource__, outlining the steps and stakeholders involved in governance.<br><br> Data transparency is critical to an organization’s security. The resource should clearly define the person(s) responsible for its upkeep, along with a channel to reach out to them if information is incorrect or outdated. The resource should include but not limit to the following:<br><br><ul><li>Mandatroy steps in the governance process (temp checks, RFCs, timelines, vote thresholds), type of election (ranked choice, single choice, first past the post, etc).</li><li>Rules of elections, and elected position descriptions and contact information.</li></ul> Along with key details on governance design, and operational rules, the governance document __SHOULD__ include information on all *__privileged roles__* (details on who can do what). Privileged roles should include information pertaining to the powers delegated to said role and identify the addresses associated with each role. For example, can anyone create a new proposal, can proposals be vetoed, are proposal executions autonomous, etc?<br><br>In addition to the governance process, all official service providers and their respective responsibilities should be detailed along with contact information for each team. <br><br>2. `[RECOMMENDED]` The DAO should maintain a repository of all DAO-related artifacts.<br><br> DAO-related artifacts include (but are not limited to) grant programs; list of all smart contracts; list of functional committees, councils and multisigs; trusted service providers; and financial reporting. We recommend using the EIP-4824 standard to facilitate this, as it allows decentralized control of data by the DAO.|
 | Ownership of assets | `[MANDATORY]` The DAO should make public a list of all assets it owns and controls. The list could include crypto tokens, ENS names and other naming services, dApps, frontends, physical assets, etc. |
 | Self defense, incident response, auditing, and vulnerability management |It is imperative to have a course of action or otherwise defensive capability for responding to security incidents and events which pose a risk to the core operations of a DAO or it's technical assets. This includes things such as CVE remediation, DNS hijacking/infrastructure compromise, KPI definitions for security event monitoring and response. The intention here is to prompt the creation of a plan - no critical details of the incident response plan need to be public. A template for inspiration is available [here](https://www.cisa.gov/sites/default/files/2024-08/Federal_Government_Cybersecurity_Incident_and_Vulnerability_Response_Playbooks_508C.pdf) (not Web3/DAO specific). While there are many overlapping security considerations with Web2 practices, it is important to take DAO specific concerns into account. Additionally, it is necessary to also consider proactive controls for things such as MFA requirements, IAM best practices and regular reviews/audits of permissions for developers or technical contributors. <br><br> 1. `[MANDATORY]` The DAO must publish a self-defense and emergency management plan.<br><br> 2. `[RECOMMENDED]` The DAO should publish a vulnerability management plan. Sample [template](https://frsecure.com/vulnerability-management-policy-template/) (not Web3/DAO specific).  |
 | Vendor/service provider management Policy | 1. `[MANDATORY]` The DAO should publish a list of vendors/service providers it relies upon.<br><br> 2. `[RECOMMENDED]` The DAO should publish a vendor management policy. [Inspiration here](https://frameworks.securityalliance.org/external-security-reviews/vendor-selection.html).<br><br>*Vendors include all 3rd party service providers that provide a good or service to the DAO, including software services that are not paid by the DAO, but used for operations, governance or other avenues*.|