...

This page also uses the following abbreviations:

Primary Document

The primary document is the "home page" for the governance framework (GF). It:

1. MUST have a DID (Decentralized Identifierdecentralized identifier) that serves as an identifier of the entire GF.
2. MUST have a unique DID URL (as defined in the DID spec) to the W3C Decentralized Identifiers 1.0 specification) to identify each specific version of the primary document.
3. MUST contain authoritative references to all other documents included in the GF, called the controlled documents.

...

1. SHOULD reference any external websites, white papers, or other helpful background materials.
2. SHOULD reference the ToIP Foundation, the ToIP stack, and the specific version of the ToIP  ToIP governance template upon which the GF is based.
3. MAY include an "Acknowledgements" section thanking contributors to the GF.

...

1. MUST explicitly specify the use of the ToIP Governance Requirements Glossary (see below).
2. MUST reference the Glossary controlled document for all other terms (see the Controlled Documents section).
3. MUST specify that all RFC 2119 keywords used with their RFC 2119 meanings are CAPITALIZED.
4. SHOULD specify any other formatting, layout, or notation conventions used in the primary document or controlled documents.

...

ToIP Governance Requirements Glossary

Localization

This section covers the policies governing languages and translations for the GF. It:

...

1. For the governing authority (or each interdependent governing authority), this section:
   
   1. MUST state the full legal identity including jurisdiction(s).
   2. MUST state the DID.
   3. SHOULD provide an LEI.
   4. MUST provide contact information for official communication to the legal entity.
   5. SHOULD provide contact information for official persons acting on behalf of the legal entity.
2. For the GF itself, this section:
   1. SHOULD provide the URL for a publicly-accessible website dedicated to the GF ("GF website").
3. The GF website SHOULD  SHOULD include:
   1. HTML versions of all documents in the GF.
   2. PDF versions of all documents in the GF.
   3. Highlighted links to the Governance Requirements controlled document(s) that specify how the governing authority itself is governed.
   4. If applicable, a primary trust mark for the GF displayed prominently on the home page and in the header of every other page.

...

1. MUST state the full legal identity of the administering authority.
   
   1. SHOULD provide the LEI.
2. MUST provide contact information for the administering authority as a legal entity.
   1. SHOULD provide contact information for official contactscontacts acting on behalf of the legal entity.
3. MUST clearly define what administrative authority the governing authority delegates to the administering authority and what decisions and processes remain the responsibility of the governing authority.

...

This states the high-level outcomes desired by the trust community through its adoption of the Governance FrameworkGF. It:

1. SHOULD specify tangible, achievable results (e.g. SMART criteria and Fit-for-purpose Purpose criteria).
2. SHOULD specify the intended overall outcomes the GF is designed to produce.
3. MUST only contain outcomes over which the GF has the authority and mechanisms to achieve within its Scopescope.
4. MUST be consistent with the Principles principles of the GF (below).

Principles

This section states the Principles principles by which all members of the trust community agree to abide. It:

1. SHOULD serve as a guide to the development of Policies policies, Rules rules, and other Requirements requirements in the GF ("Principles principles guide Policies policies").
2. SHOULD refer to existing Principles principles whenever possible (whether defined by ToIP or other sources).
3. SHOULD be referenced (along with any other relevant parts of the GF) in any Legal Agreement (to help clarify intent).
4. MUST NOT include Requirements requirements (e.g., using capitalized RFC 2119 keywords keywords) for which either human or machine conformance can be directly tested — those should be stated as Requirements requirements elsewhere in the GF.

General Requirements

This section contains Requirements that requirements that apply to the GF as a whole and not just in the context of a particular controlled document. It:

1. SHOULD include the Requirements that requirements that:
   1. Apply generally to governance of the entire trust community.
   2. Apply to the structure of the GF, e.g., what controlled documents must be specified by whom and applied to whom.
   3. Guide the development of more specific Requirements within requirements within the controlled documents.
2. SHOULD NOT include Requirements that requirements that apply only within the context of a specific category addressed by one of the controlled documents.
3. MUST include any Responsible Use Policies responsible use policies that apply to infrastructure governed by the GF.
4. MUST include any Regulatory Compliance Policies that regulatory compliance policies that are not specified within particular controlled documents.
5. SHOULD include a Code of Conduct that applies to all trust community members.

Revisions

This section contains the specific Requirements governing requirements governing revisions to the GF. It:

1. MUST include Requirements specifying how requirements specifying:
   1. How any revisions to the GF will be developed, reviewed, and approved.
   MUST include Requirements for how all
   1. How any new versions will be uniquely identified with a DID URL.
2. SHOULD include at least one public review period for any GF that will be available to the public.
3. SHOULD NOT include any other types of Governance Requirements governance requirements for the governing authority or interdependent Governing Authorities interdependent governing authorities (those should be defined in controlled documents in the Governance Requirements category).

...

This section applies to GFs that permit extensions via the incorporation of other GFs extension GFs (a common feature of some ecosystem GFs). It:

1. MUST state whether the GF can be extended.
2. MUST specify the requirements an Extension extension GF must meet in order to be approved.
3. MUST specify the process by which an Extension GF an extension GF can be approved.
4. MUST define an authoritative mechanism for registration, activation, and deactivation of an approved Extension extension GF.
5. MUST define the requirements for notification of the of trust community community members about activation or deactivation of an approved Extension extension GF.

Schedule of Controlled Documents 

...

1. MUST include authoritative references to all controlled documents in the GF.
2. MUST identify the exact version of each controlled document with a unique, permanent DID or DID URL.
3. SHOULD include a Web link to each controlled documents in the Web version of on the GF website.
4. SHOULD include a brief description of the purpose and scope of each controlled document to make it easy for readers to navigate the GF.

Controlled Documents

Each Controlled Document Each controlled document covers a specific area of the GF. The following sections are categories of controlled documents where  where each category MAY include zero or more controlled documents.contain more than one document. Most (but not all) categories are OPTIONAL.

Glossary

The Glossary This category provides a common basis for terminology. It:

1. SHOULD be a single controlled document  for each applicable language (even if it is organized by categories or other heuristics).
2. SHOULD provide a common reference for all possibly ambiguous terms used throughout the GF.
3. SHOULD reference the ToIP Glossary—or tagged subset(s) of the ToIP Glossary—for all terms defined therethe ToIP Core Glossary or any other relevant ToIP glossary for all terms with established definitions in the overall scope of ToIP.
4. SHOULD conform to standard requirements for  for a glossary, i.e., list all terms alphabetically (by language) for easy reference.
5. MAY tag terms by category or usage.
6. MAY specify that terms specific to one controlled document are defined in that controlled document.

...

This category includes links to an ISO 27005 (or compatible) risk assessment for managing risk. Controlled documents in this category:

• SHOULD identify key risks that MAY negatively affect the achievement of the GF's purpose and objectives and objectives within its Scope scope.
• SHOULD include a Risk Assessment risk assessment process output that provides an assessment of each key risk that the GF is designed to address and mitigate.
• SHOULD assess which Roles roles and Processes processes are vulnerable to each risk and how they are affected.
• MAY SHOULD include a Risk Treatment Plan (RTP) for risk treatment plan specifying how identified risks are to be treated (e.g. mitigated, avoided, accepted or transferred); however, all risks that are to be mitigated by Mandates in the GF SHOULD be identified.

Trust Assurance and Certification

This category specifies Trust Criteria for Governed Parties trust criteria for governed parties be held accountable against Requirements of requirements of the GF. Controlled documents in this category:

1. SHOULD include a Trust Assurance Framework trust assurance framework document that defines a scheme in which Governed Parties which governed parties assert compliance with the Policies of policies of the GF and the mechanisms of assurance over those assertions.
2. SHOULD (if applicable) define the roles of Auditors auditors and Auditor Accreditors auditor accreditors and the directives governing their actions.
3. SHOULD (if applicable) define the roles of Certifying Parties of certifying parties and the requirements governing  governing their actions and relationships with the governing authority, Auditors, and Auditor Accreditorsauditors and auditor accreditors.
4. SHOULD (if applicable) include requirements supporting  supporting the development, licensure, and usage of one or more Trust Marks trust marks.

Governance Requirements

These are the Requirements for the requirements for governing the GF as a whole. Controlled documents in this category:

1. MUST include Controlled Documents controlled documents that specify Governance governance requirements (e.g., Charter, Bylaws, Operating Rules, and so on) for:
   1. The primary governing authority (or all interdependent governing authorities).
   2. If applicable, the administering authority. 
2. SHOULD address any Antitrust Policies, Intellectual Property Rights antitrust policies, intellectual property rights (IPR) Policies policies, Confidentiality Policiesconfidentiality policies, or other Requirements requirements for regulatory compliance under which the trust community members agree to operate.
3. SHOULD include any Requirements requirements governing enforcement of the GF and how Dispute Resolution dispute resolution will be handled.

Business Requirements

These are the requirements governing  governing the business model(s) and business rules to be followed by the trust community. Controlled documents in this category:

1. SHOULD clearly explain the exchange(s) of value within the trust community for which the community the GF is designedgoverning.
2. SHOULD define the Policies policies and/or Rules governing rules governing how and when these exchanges of value take place.
3. SHOULD define the Requirements for requirements for the use of any Decision Support Systems decision support systems.
4. SHOULD define how all trust community members will be held accountable for their actions in these exchanges.
5. SHOULD define how the governing authority, administering authority, and the GF are sustainable under these requirements.

...

These are the requirements governing technical interoperability. Controlled documents in this category:

1. MUST specify how Members of the trust community how trust community members will interoperate technically using the ToIP Technology Stack the ToIP technology stack by reference to any relevant ToIP Specifications specifications and ToIP Recommendations recommendations.
2. SHOULD include any additional Specifications specifications and/or specification profiles that are specific to the technical operation of this trust community.
3. SHOULD reference one or more ToIP Glossaries or other Glossaries as glossaries as needed.
4. SHOULD reference any test suites and testing requirements.

Information Trust Requirements

These are the requirements governing information security, availability, processing integrity, confidentiality and privacy as these terms are defined by requirements for the five categories of trust service criteria defined by the American Institute of Certified Public Accountants (AICPA) Assurance Services Executive Committee (ASEC). These can be addressed by internal controls as describe by the Committee on the Sponsoring Organizations of the Treadway Commission (COSO) Guidance on Internal Control. Controlled documents in this category:

1. MUST specify how Members of the trust community will ensure the following categories of Information Trustthe baseline requirements for trust community members with regard to:
   1. Information security
   2. Information availability
   3. Information processing integrity
   4. Information confidentiality
   5. Information privacy
2. SHOULD specify the relevant Information Trust Policies by information trust policies by reference to:
   1. ToIP Specifications and ToIP Recommendations specifications and recommendations.
   2. Other regulatory or industry standards.
   3. GF-Specific Policiesspecific policies.
   4. GF-Compliant Decision Support Systemscompliant decision support systems.
   5. Trust community member-specific policies.

Inclusion, Equitability, and Accessibility Requirements

These are the Policies governing policies governing how the GF enables fair and equal access to all. Controlled documents in this category:

1. MUST specify how trust community members will enable and promote inclusion, equitability, and accessibility by reference to:
   1. ToIP Specifications and ToIP Recommendations specifications and recommendations.
   2. Other regulatory or industry standards.
   3. GF-Specific Policiesspecific policies.
   4. GF-Compliant Decision Support Systemscompliant decision support systems.
   5. trust Trust community member-specific policies.
2. SHOULD specifically address how the GF is designed to help bridge (or eliminate) the digital divide.

...

1. MUST include all specified legal agreements or contracts between Members and/or the governing authority.
2. SHOULD reference the Glossary GF glossary document(s) for all terms not defined internally to the agreement or contract.
3. MUST clearly state the Governed Parties to governed parties to whom these legal agreements apply.
4. MUST define or reference all relevant accountability and enforcement mechanisms.
5. SHOULD reference any other relevant requirements in the balance of the GF.

...