Versions Compared

Old Version 68

changes.mady.by.user Drummond Reed

Saved on

compared with

New Version 69

changes.mady.by.user Drummond Reed

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

Info
titleNEW
  • Requirements include any combination of Policies, Rules, and SpecificationsMachine-Testable Requirements and Human-Auditable Requirements. Unless otherwise stated, all Requirements MUST be expressed as defined in RFC 2119. 
    • Mandates are Requirements that use a MUST, MUST NOT, SHALL, SHALL NOT or REQUIRED keyword.
    • Recommendations are Requirements that use a SHOULD, SHOULD NOT, or RECOMMENDED keyword.
    • Options are Requirements that use a MAY or OPTIONAL keyword.
  • Machine-Testable Requirements are Requirements  are those with which compliance can be verified using an automated test suite and appropriate scripting or testing software.
    • Rules are Machine-Testable Requirements that are written in a Machine-Readable language and can be processed by a Rules Engine. They are expressed in a structured rules language as specified by the GF.
  • Human-Auditable Requirements are Requirements  are those with which compliance can only be verified by an audit of people, processes, and procedures.
    • Policies are Human-Auditable Requirements written using standard terms for conformance and auditingterminology. For Policies using in ToIP Governance Frameworks, the full range of standard terminology is  RFC 2119 keywords apply, i.e., "SHOULD", "MAY", and "RECOMMENDED" all . Note that all RFC 2119 keywords have weight from an auditing perspective. An implementer MUST explain why a SHOULD or RECOMMENDED requirement was not implemented and SHOULD explain why a MAY requirement was implemented.
  • Specifications are documents containing any combination of Machine-Readable Testable Requirements and Human-Auditable Requirements needed to produce technical interoperability.

...

  1. SHOULD have a reference to the ToIP Foundation, the ToIP Stack, and the specific version of the ToIP Governance Template from which it was derived.
  2. MAY include an "Acknowledgements" section to acknowledge the contributors to the GF.
Info
titleNew

Governance Authority and Governing Party

This section asserts the legal authority for governance of the GF. It:

  1. MUST state whether the Governance Authority or interdependent Governance Authorities are the same as the Governing Party.
  2. MUST state the full legal identity of each Governance Authority and the Governing Party.
    1. SHOULD provide an LEI for each.
  3. MUST provide contact information for the Governing Party.
  4. SHOULD provide a publicly-accessible website for accessing the GF.
  5. It RECOMMENDED that this website:
    1. Be an independent dedicated website with its own  URL for portability and ease of management.
    2. If applicable, use a URL closely associated with the primary Trust Mark for the GF and display this Trust Mark prominently on the home page.
    3. Include HTML versions of all documents in the GF.
    4. Include PDF versions of all documents in the GF.
    5. Highlight the documents in the Governance Requirements section that specify how the Governance Authority itself is governed.
    6. Provide specific contact information for each Individual responsible in a public-facing Role for administering the GF and accepting public inquires or feedback.

Purpose

This is a short, clear statement of the overall purpose (mission) of the GF. It:

...

This section contains the specific Requirements governing revisions to the GF. It does not include Governance Requirements for the Governance Authority or interdependent Governance Authorities (those should be defined in Controlled Documents in the Governance category). It:

  1. MUST state the full legal identity and contact information for the primary Governance Authority or interdependent Governance Authorities.MUST include Requirements specifying how any revisions to the GF will be developed, reviewed, and approved.
  2. MUST include Requirements for how all new versions will be identified with a DID URL.
  3. SHOULD include at least one public review period for any GF that will be available to the public.

...

Anchor
risk-assessment
risk-assessment
Risk Assessment

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 within its Scope.
  • SHOULD include a 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 and Processes are vulnerable to each risk and how they are affected.
  • MAY include a Risk Treatment Plan (RTP) for how identified risks are 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

...

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

  1. MUST specify the primary Governance Authority or all interdependent Governance Authorities (if any).MUST include Controlled Documents that specify Governance requirements for the primary Governance Authority (or all interdependent Governance Authorities (Authorities, or if applicable the Governing Entity), e.g., Charter, Bylaws, Operating Rules, etc.)
  2. SHOULD address any Antitrust Policies, Intellectual Property Rights (IPR) Policies, Confidentiality Policies, or other Requirements for regulatory compliance under which the Trust Community Members agree to operate.
  3. SHOULD include any Requirements governing enforcement of the GF and how Dispute Resolution will be handled.

...

  1. SHOULD clearly explain the exchange(s) of value within the Trust Community for which the GF is designed.
  2. SHOULD define the Policies and/or Rules governing how and when these exchanges of value take place.
  3. SHOULD define the Requirements for the use of any Rules Engines or 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 Governance Authority, Governing Entity, and the GF are sustainable under these RulesRequirements.

Technical Requirements

These are the Requirements governing technical interoperability. Controlled Documents in this category:

...

These are the Requirements governing information security, privacy, availability, confidentiality and processing integrity as these terms are defined by the the Committee on the Sponsoring Organizations of the Treadway Commission - (COSO) Guidance on Internal Control - Integrated Framework. Controlled Documents in this category:

  1. MUST specify how Members of the Trust Community will ensure the following categories of Information Trust:
    1. Information security
    2. Information privacy
    3. Information availability
    4. Information confidentiality
    5. Information processing integrity
  2. SHOULD specify the relevant Information Trust Policies by reference to:
    1. ToIP Standard Specifications (TSS).
    2. Other regulatory or industry standards.
    3. GF-specific Policies.
    4. GF-compliant Rules Engines and Decision Support Systems.
    5. Trust Community Member-specific Policies.

...

  1. MUST specify how Members of the Trust Community will enable and promote inclusion, equitability, and accessibility by reference to:
    1. ToIP Standard Specifications (TSS).
    2. Other regulatory or industry standards/guidelines.
    3. GF-specific Policies.
    4. GF-compliant Rules Engines and Decision Support Systems.
    5. Member-specific Policies.
  2. SHOULD specifically address how the GF is designed to help bridge (or eliminate) the digital divide.

...