You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
As a tool developer, tool user, or constraint author, I would like the expectation of attachments to be clearly specified so that I can consistently meet the expectation.
Goals
-Augment the FedRAMP OSCAL profiles with annotations that indicate which response points are expected to utilize reference a policy, process, plan or similar attachment.
This indication should include:
the nature of the expected attachment (policy, procedure, plan, etc.)
the ability to indicate when any one of two or more attachment types are acceptable (i.e. attachment may be either a plan or a procedure)
whether a failure to provide the expected attachment results in an ERROR or WARNING.
An ERROR is used when the attachment is explicitly required.
A WARNING is used when an attachment is recommended or is typically part of control satisfaction, but is not strictly required.
A Pull Request (PR) is submitted that fully addresses the goals of this User Story. This issue is referenced in the PR.
Other information
This will likely need to be accomplished with FedRAMP extensions to core OSCAL.
This is best accomplished when we are ready to perform the larger refactoring effort on the FedRAMP profiles as was intended by #604.
The text was updated successfully, but these errors were encountered:
This is a ...
improvement - something could be better
This relates to ...
User Story
As a tool developer, tool user, or constraint author, I would like the expectation of attachments to be clearly specified so that I can consistently meet the expectation.
Goals
-Augment the FedRAMP OSCAL profiles with annotations that indicate which response points are expected to utilize reference a policy, process, plan or similar attachment.
Dependencies
No response
Acceptance Criteria
Other information
This will likely need to be accomplished with FedRAMP extensions to core OSCAL.
This is best accomplished when we are ready to perform the larger refactoring effort on the FedRAMP profiles as was intended by #604.
The text was updated successfully, but these errors were encountered: