---
# System prepended metadata

title: OSCAL Community Collaboration Committee (C3)

---

# OSCAL Community Collaboration Committee (C3)

## Charter

### Table of Contents

1. [Objectives](#Objectives)
2. [Roles](#Roles)
3. [Scope](#Scope)
4. [Qualification](#Qualification)
5. [Structure](#Structure)
6. [Selection](#Selections)
7. 


### Objectives 

The charter specifies the composition of the Collaboration  Advisory Committee (CAC), including the number of members, their qualifications, and the process for selecting and appointing them.

The Collaboration Advisory Committee will be established to:
- Support risk management and compliance automation with OSCAL by further adoption of OSCAL by the community, 
- Support future OSCAL research and development in alignment with the community's needs,
- Support NIST's communiaction with the community,
- Enhance the community's feedback and contributions which have been adhoc and unreliable in the past,
- Serve as the community's liason to NIST.

The CAC's activities will focus its activities around 2 main activities:
1. Working with the community to 
    1.a - gather feedback from the community on OSCAL issues of high importance to the community
    1.b - expand the community members' engagement with OSCAL research, development, maintenance and education
2. Provide expert advice to NIST OSCAL Program on industry trends, regulations, and best practices.


### Roles

To achive its goals, the CAC will have to assume the following functions:

**Convene**
- Convenes periodic meetings to bring forward and discuss critical OSCAL research, engineering and adoption issues, document the sponsors of the requested research topics and engineering issues in order to prioritise community's requests.
 
**Represent** 
- Prepares information describing the community's use of OSCAL, and presents the cohesive trends, goals, and needs of the community.
- Regularly surveys the community to identify blockers and friction in adopting and using OSCAL and document the activities or OSCAL new features that will have the most impact toward adoption, development acceleration, and usage.
- Gathers community's feedback on NIST OSCAL research and engineering processes, and makes suggestions for improvements.
- Ensures NIST OSCAL team receives continuous, timely, quality feedback on questions and proposals to decrease reseearche and engineering cycles time.

**Educate** 
- Engages the community in supporting NIST OSCAL team's effort on generating documentation, examples and tutorials to make OSCAL easier to use.
- Organizes a mentorship program for the new members of the  OSCAL community.
- Supports the OSCAL MeetUps or similar community educational gathering.

**Promote** 
- Increases the number of organizations, tools, and compliance projects using OSCAL.


### Scope [TBD]

The section will cover 
- why OSCAL community and OSCAL Program need a CAC that represents the community, 
- how NIST will announce it and 
- how will the members be seleted, 
- size of the AB (TBD - odd number preferred)
- life of membership, no consecutive renewals (? unless), 
- diversity (gov non-gov, content consumer, tool vendor) 


### Qualification

The CAC's expertise needs to cover:
- risk management, 
- security assessment, 
- prior knowledge of OSCAL models and tools, 
- proven knowledge of OSCAL implementation and models.

Qualifications:
* Working professionally in compliance with OSCAL
* at least 4 years experience with risk management and compliance
* Commit 2 to 4 hours a week
* Represent an organization that is able to demonstrate the use of OSCAL or support of OSCAL
  
### Representation

- Proposal #1:
    * tool vendors
    * agencies
    * CSP
    * system integrators
    * assessment orgs
    * international community 
    * Working groups | other governments (?)

- Proposal #2 (with votting members):
    * 3 agency members
    * 2 GRC vendors
    * 2 non-vendor members
    * 1 FedRAMP PMO member
    * optional rotate specific SME non-voting  members:
        * security SME
        * procurement SME
        * 3PAO SME
        * others as needed/identified

#### Structure

The committee will have the following roles: 
* Chair 
* Vice chair 
* Secretary
* Federal Adoption Champion 
* non-Federal Adoption Champion 
* Education Champion
* Member 


### Selection

**Nominations** 
- Nomination will require:
    - One paragraph description of the represented oganization's adoption of OSCAL (including the organization's customers benefiting from the OSCAL adoption)
    - One paragraph of the proposed member expertise of OSCAL. Recommendations/endorsments by other parties outside the member's organization are desired
    - Be a regular attendee at NIST OSCAL meetings provides extra points
    
**Voting**
- Voting should be done through polling during a virtual meeting or through Google form filled in by the community members.


**Terms and Renewals**

The CAC members will be elected for one year, but a mid year rotation of the roles is recommended


The CAC members, regardless of the role, should not be part of the CAC for more than a year, to avoid abusing the role for personal advantages and to allow other representative members of the community to be part of the CAC.

A mid-term (6 months) roles-rotation should take place.

In collaboration with the NIST OSCAL Strategic Director as election observer, the 2 members will be responsible for the election of the new CAC.

The new CAC is elected in the 11th month of the current CAC and the newly elected CAC members are shadowing existing members to learn and transfer the roles


[wap feedback] - Two things need to be clarified:

1. Scope of decision making. From the above it seems that the AB's decisions with respect to OSCAL are limited to the recommendations it makes. ("prioritize committee requests"). If this is the case, then the mechanisms by which AB members participate in OSCAL (not just the AB) are left unstated. Presumably these would be the same mechanisms as any community member, correct? Maybe this needs to be stated. In other words, AB members are expected to wield influence - but not through the AB process itself, which only "makes requests".

2. Governance going forward. If the committee wishes to revise its own constitution - for example, add members, invite guests ('non-member participants'?) - or change how members are found/selected/voted in - are there means to do this? If not, how will adjustments to committee (process, responsibilities) be made and by whom?

... and a half-thing - voting using a public-facing web-based mechanism is very vulnerable to bad outcomes and doesn't guarantee representation.

*However*, these are questions that might best be posed with community members, not decided on from the inside.

Accordingly, maybe the priority should not be refining the points here, but rather getting this in front of stakeholders.





