This contains all modules common to the assessment plan, assessment results, and POAM models.
+The root of the OSCAL Assessment Plan format is assessment-plan.
The root of the OSCAL Assessment Results format is assessment-results.
The root of the OSCAL Plan of Action and Milestones (POA&M) format is plan-of-action-and-milestones.
This value may be one of:
+back-matter resource in this or an imported document (see linking to another OSCAL object).The specified control-id must be a valid value within the baseline identified by the target system's SSP via the import-profile statement.
assessment method can be used to reference the data item locally or globally (e.g., in an imported OSCAL instance). This UUID should be assigned per-subject, which means it should be consistently used to identify the same subject across revisions of the document.activity can be used to reference the data item locally or globally (e.g., in an imported OSCAL instance). This UUID should be assigned per-subject, which means it should be consistently used to identify the same subject across revisions of the document.step (in a series of steps) can be used to reference the data item locally or globally (e.g., in an imported OSCAL instance). This UUID should be assigned per-subject, which means it should be consistently used to identify the same subject across revisions of the document.This can be optionally used to define the set of controls and control objectives that are assessed by this step.
+Identifies the roles, and optionally the parties, associated with this step that is part of an assessment activity.
+Since multiple party-uuid entries can be provided, each role-id must be referenced only once.
This can be optionally used to define the set of controls and control objectives that are assessed or remediated by this activity.
+Since responsible-role associates multiple party-uuid entries with a single role-id, each role-id must be referenced only once.
Since responsible-role associates multiple party-uuid entries with a single role-id, each role-id must be referenced only once.
task can be used to reference the data item locally or globally (e.g., in an imported OSCAL instance). This UUID should be assigned per-subject, which means it should be consistently used to identify the same subject across revisions of the document.Identifies the person or organization responsible for performing a specific role defined by the activity.
+Since responsible-role associates multiple party-uuid entries with a single role-id, each role-id must be referenced only once.
The assessment subjects that the activity was performed against.
+Identifies the person or organization responsible for performing a specific role related to the task.
+ +Used to select a control for inclusion by the control's identifier. Specific control statements can be selected by their statement identifier.
+Used to select a control for exclusion by the control's identifier. Specific control statements can be excluded by their statement identifier.
+The include-all, specifies all control identified in the baseline are included in the scope if this assessment, as specified by the include-profile statement within the linked SSP.
Any control specified within exclude-controls must first be within a range of explicitly included controls, via include-controls or include-all.
Used to select a control objective for inclusion by the control objective's identifier.
+Used to select a control objective for exclusion by the control objective's identifier.
+The include-all field, specifies all control objectives for any in-scope control. In-scope controls are defined in the control-selection.
Any control objective specified within exclude-controls must first be within a range of explicitly included control objectives, via include-objectives or include-all.
In the context of an assessment plan, this construct is used to identify the controls and control objectives that are to be assessed. In the context of an assessment result, this construct is used to identify the actual controls and objectives that were assessed, reflecting any changes from the plan.
+When resolving the selection of controls and control objectives, the following processing will occur:
+1. Controls will be resolved by creating a set of controls based on the control-selections by first handling the includes, and then removing any excluded controls.
+2. The set of control objectives will be resolved from the set of controls that was generated in the previous step. The set of control objectives is based on the control-objective-selection by first handling the includes, and then removing any excluded control objectives.
+assessment subject placeholder can be used to reference the data item locally or globally (e.g., in an imported OSCAL instance). This UUID should be assigned per-subject, which means it should be consistently used to identify the same subject across revisions of the document.task can be used to reference the data item locally or globally (e.g., in an imported OSCAL instance). This UUID should be assigned per-subject, which means it should be consistently used to identify the same subject across revisions of the document.local-definitions of an Assessment Plan or Assessment Results.local-definitions of an Assessment Plan or Assessment Results.location defined in the metadata of the SSP, Assessment Plan, or Assessment Results.party in the metadata of the SSP, Assessment Plan, or Assessment Results.user defined in the SSP, or in the local-definitions of an Assessment Plan or Assessment Results.Processing of an include/exclude pair starts with processing the include, then removing matching entries in the exclude.
+uuid-ref within a subject.The subject reference UUID could point to an item defined in the SSP, AP, or AR.
+Tools should check look for the ID in every file imported directly or indirectly.
+Used to add any components for tools used during the assessment. These are represented here to avoid mixing with system components.
+The technology tools used by the assessor to perform the assessment, such as vulnerability scanners. In the assessment plan these are the intended tools. In the assessment results, these are the actual tools used, including any differences from the assessment plan.
+assessment platform can be used to reference the data item locally or globally (e.g., in an imported OSCAL instance). This UUID should be assigned per-subject, which means it should be consistently used to identify the same subject across revisions of the document.Since responsible-party associates multiple party-uuid entries with a single role-id, each role-id must be referenced only once.
Since multiple assessment component entries can be provided, each component must have a unique uuid.
The target will always be a reference to: 1) a control statement, or 2) a control objective. In the former case, there is always a single top-level statement within a control. Thus, if the entire control is targeted, this statement identifier can be used.
+type.Reason may contain any value, and should be used to communicate additional information regarding the status.
+The implementation-status is used to qualify the status value to indicate the degree to which the control was found to be implemented.
finding can be used to reference the data item locally or globally (e.g., in an imported OSCAL instance). This UUID should be assigned per-subject, which means it should be consistently used to identify the same subject across revisions of the document.Used to identify the individual and/or tool generated this finding.
+observation can be used to reference the data item locally or globally (e.g., in an imported OSCAL instance). This UUID should be assigned per-subject, which means it should be consistently used to identify the same subject across revisions of the document.Used to identify the individual and/or tool that gathered the evidence resulting in the observation identification.
+Identifies who was interviewed, or what was tested or inspected.
+This value may be one of:
+back-matter resource in this or an imported document (see linking to another OSCAL object).Identifies the person or organization responsible for performing a specific role defined by the activity.
+The assessment subjects that the task was performed against.
+The assessment subjects that the task identified, which will be used by another task through a subject-placeholder reference. Such a task will "consume" these subjects.
+Since responsible-party associates multiple party-uuid entries with a single role-id, each role-id must be referenced only once.
http://fedramp.gov/ns/oscal instead.This value must be an absolute URI that serves as a naming system identifier.
+This value may be one of:
+back-matter resource in this or an imported document (see linking to another OSCAL object).risk can be used to reference the data item locally or globally (e.g., in an imported OSCAL instance). This UUID should be assigned per-subject, which means it should be consistently used to identify the same subject across revisions of the document.Used to identify the individual and/or tool that identified this risk.
+mitigating factor can be used to reference the data item locally or globally (e.g., in an imported OSCAL instance). This UUID should be assigned per-subject, which means it should be consistently used to identify the same subject across revisions of the document.implementation statement can be used to reference the data item locally or globally (e.g., in an imported OSCAL instance). This UUID should be assigned per-subject, which means it should be consistently used to identify the same subject across revisions of the document.Links identifiable elements of the system to this mitigating factor, such as an inventory-item or component.
+risk log entry can be used to reference the data item locally or globally (e.g., in an imported OSCAL instance). This UUID should be assigned per-subject, which means it should be consistently used to identify the same subject across revisions of the document.Identifies a change in risk status made resulting from the task described by this risk log entry. This allows the risk's status history to be captured as a sequence of risk log entries.
+This is used to identify the task(s) that this log entry was generated for.
+metadata about the specific actor that generated this descriptive data.
+http://fedramp.gov/ns/oscal instead.This value must be an absolute URI that serves as a naming system identifier.
+class can be used to specify 'initial' and 'adjusted' risk states.class can be used to specify 'initial' and 'adjusted' risk states.class can be used to specify 'initial' and 'adjusted' risk states.risk response can be used to reference the data item locally or globally (e.g., in an imported OSCAL instance). This UUID should be assigned per-subject, which means it should be consistently used to identify the same subject across revisions of the document.Used to identify the individual and/or tool that generated this recommended or planned response.
+asset can be used to reference the data item locally or globally (e.g., in an imported OSCAL instance). This UUID should be assigned per-subject, which means it should be consistently used to identify the same subject across revisions of the document.Identifies an asset associated with this requirement, such as a party, system component, or inventory-item.
+part can be used to reference the data item locally or globally (e.g., in an ported OSCAL instance). This UUID should be assigned per-subject, which means it should be consistently used to identify the same subject across revisions of the document.This value must be an absolute URI that serves as a naming system identifier.
+When a ns is not provided, its value should be assumed to be http://csrc.nist.gov/ns/oscal and the name should be a name defined by the associated OSCAL model.
name. This can be used to further distinguish or discriminate between the semantics of multiple parts of the same control with the same name and ns.A class can be used in validation rules to express extra constraints over named items of a specific class value.
A class can also be used in an OSCAL profile as a means to target an alteration to control content.
A part provides for logical partitioning of prose, and can be thought of as a grouping structure (e.g., section). A part can have child parts allowing for arbitrary nesting of prose content (e.g., statement hierarchy). A part can contain prop objects that allow for enriching prose text with structured name/value information.
A part can be assigned an optional id, which allows for internal and external references to the textual concept contained within a part. A id provides a means for an OSCAL profile, or a higher layer OSCAL model to reference a specific part within a catalog. For example, an id can be used to reference or to make modifications to a control statement in a profile.
Use of part and prop provides for a wide degree of extensibility within the OSCAL catalog model. The optional ns provides a means to qualify a part's name, allowing for organization-specific vocabularies to be defined with clear semantics. Any organization that extends OSCAL in this way should consistently assign a ns value that represents the organization, making a given namespace qualified name unique to that organization. This allows the combination of ns and name to always be unique and unambiguous, even when mixed with extensions from other organizations. Each organization is responsible for governance of their own extensions, and is strongly encouraged to publish their extensions as standards to their user community. If no ns is provided, the name is expected to be in the "OSCAL" namespace.
To ensure a ns is unique to an organization and naming conflicts are avoided, a URI containing a DNS or other globally defined organization name should be used. For example, if FedRAMP and DoD both extend OSCAL, FedRAMP will use the ns
+ http://fedramp.gov/ns/oscal, while DoD might use the ns
+ https://defense.gov for any organization specific name.
Tools that process OSCAL content are not required to interpret unrecognized OSCAL extensions; however, OSCAL compliant tools should not modify or remove unrecognized extensions, unless there is a compelling reason to do so, such as data sensitivity.
+The OSCAL assessment plan format is used to describe the information typically provided by an assessor during the preparation for an assessment.
+The root of the OSCAL assessment plan format is assessment-plan.
+
assessment plan can be used to reference the data item locally or globally (e.g., in an imported OSCAL instance). This UUID should be assigned per-subject, which means it should be consistently used to identify the same subject across revisions of the document.Used by the SAP to import information about the system being assessed.
+Used to add any components, not defined via the System Security Plan (AR->AP->SSP)
+Used to add any inventory-items, not defined via the System Security Plan (AR->AP->SSP)
+Used to add any users, not defined via the System Security Plan (AR->AP->SSP)
+Since multiple component entries can be provided, each component must have a unique uuid.
A given uuid must be assigned only once to a user.
The OSCAL assessment results format is used to describe the information typically provided by an assessor following an assessment.
+The root of the OSCAL assessment results format is assessment-results.
+
assessment result can be used to reference the data item locally or globally (e.g., in an imported OSCAL instance). This UUID should be assigned per-subject, which means it should be consistently used to identify the same subject across revisions of the document.Used by the SAR to import information about the original plan for assessing the system.
+assessment result can be used to reference the data item locally or globally (e.g., in an imported OSCAL instance). This UUID should be assigned per-subject, which means it should be consistently used to identify the same subject across revisions of the document.Used to add any components, not defined via the System Security Plan (AR->AP->SSP)
+Used to add any inventory-items, not defined via the System Security Plan (AR->AP->SSP)
+Used to add any users, not defined via the System Security Plan (AR->AP->SSP)
+This needs to be defined in the results if an assessment platform used is different from the one described in the assessment plan. Else the platform(s) defined in the plan may be referenced within the results.
+Since multiple component entries can be provided, each component must have a unique uuid.
A given uuid must be assigned only once to a user.
The Assessment Results control-selection ignores any control selection in the Assessment Plan and re-selects controls from the baseline identified by the SSP.
The Assessment Results control-objective-selection ignores any control objective selection in the Assessment Plan and re-selects control objectives from the baseline identified by the SSP.
Any additional control objectives defined in the Assessment Plan local-definitions do not need to be re-defined in the Assessment Results local-definitions; however, if they were explicitly referenced with an Assessment Plan control-objective-selection, they need to be selected again in the Assessment Results control-objective-selection.
Since responsible-party associates multiple party-uuid entries with a single role-id, each role-id must be referenced only once.
assessment log entry can be used to reference the data item locally or globally (e.g., in an imported OSCAL instance). This UUID should be assigned per-subject, which means it should be consistently used to identify the same subject across revisions of the document.This value may be one of:
+back-matter resource in this or an imported document (see linking to another OSCAL object).The OSCAL Control Catalog format can be used to describe a collection of security controls and related control enhancements, along with contextualizing documentation and metadata. The root of the Control Catalog format is catalog.
Back matter including references and resources.
+uuid of the source profile from which the catalog was produced by profile resolution.uuid of the profile from which the catalog was produced by profile resolution.Catalogs may use one or more group objects to subdivide the control contents of a catalog.
A class can be used in validation rules to express extra constraints over named items of a specific class value.
A class can also be used in an OSCAL profile as a means to target an alteration to control content.
Catalogs can use the catalog group construct to organize related controls into a single grouping, such as a family of controls or other logical organizational structure.
A group may have its own properties, statements, parameters, and references, which are inherited by all controls of that are a member of the group.
A class can be used in validation rules to express extra
+ constraints over named items of a specific class
+ value.
A class can also be used in an OSCAL profile as a means to
+ target an alteration to control content.
control. For example, a
+ value of 'withdrawn' can indicate that the control has
+ been withdrawn and should no longer be used.Nested statement parts are "item" parts.
+Objectives can be nested.
+Assessment objects appear on assessment methods.
+Each security or privacy control within the catalog is defined by a distinct control instance. Controls may be as complex or as simple as a catalog defines them. They may be decomposed or further specified into child control objects, for example to represent control enhancements or specific breakouts of control functionality, to be maintained as discrete requirements. Controls may also contain structured parts (using part) and they may be grouped together in families or classes with group.
Control structures in OSCAL will also exhibit regularities and rules that are not codified in OSCAL but in its applications or domains of application. For example, for catalogs describing controls as defined by NIST SP 800-53, a control must have a part with the name "statement", which represents the textual narrative of the control. This "statement" part must occur only once, but may have nested parts to allow for multiple paragraphs or sections of text. This organization supports addressability of this data content as long as, and only insofar as, it is consistently implemented across the control set. As given with these model definitions, constraints defined and assigned here can aid in ensuring this regularity; but other such constraints and other useful patterns of use remain to be discovered and described.
+This format represents a combination of all of the OSCAL models.
+The OSCAL Component Definition Model can be used to describe the implementation of controls in a component or a set of components grouped as a capability. A component can be either a technical component, or a documentary component.
A technical component is a component that is implemented in hardware (physical or virtual) or software. Suppliers may document components in an OSCAL component definition that describes the implementation of controls in their hardware and software.
+A documentary component is a component implemented for a documented process, procedure, or policy. Suppliers may document components in an OSCAL component definition that describes the implementation of controls in their process, procedure, or policy.
+The information provided by a technical or documentary component can be used by component consumers to provide starting narratives for documenting control implementations in an OSCAL SSP.
+The root of the OSCAL Implementation Layer Component Definition model is component-definition.
Since multiple component entries can be provided, each component must have a unique uuid.
A given component must not be referenced more than once within the same capability.
This value may be one of:
+back-matter resource in this or an imported document (see linking to another OSCAL object).Used for service components to define the protocols supported by the service.
Since responsible-role associates multiple party-uuid entries with a single role-id, each role-id must be referenced only once.
Components may be products, services, APIs, policies, processes, plans, guidance, standards, or other tangible items that enable security and/or privacy.
+The type indicates which of these component types is represented.
A group of components may be aggregated into a capability. For example, an account management capability that consists of an account management process, and a Lightweight Directory Access Protocol (LDAP) software implementation.
Capabilities are expressed by combining one or more components.
+A given component must not be referenced more than once within the same capability.
component.This value may be one of:
+back-matter resource in this or an imported document (see linking to another OSCAL object).Since multiple set-parameter entries can be provided, each parameter must be set only once.
Use of set-parameter in this context, sets the parameter for all controls referenced by any implemented-requirement contained in this context. Any set-parameter defined in a child context will override this value. If not overridden by a child, this value applies in the child context.
Since multiple set-parameter entries can be provided, each parameter must be set only once.
Since responsible-role associates multiple party-uuid entries with a single role-id, each role-id must be referenced only once.
Since statement entries can be referenced using the statement's statement-id, each statement must be referenced only once.
Implemented requirements within a component or capability in a component definition provide a means for component suppliers to suggest possible control implementation details, which may be used by a different party (e.g., component consumers) when authoring a system security plan. Thus, these requirements defined in a component definition are only a suggestion of how to implement, which may be adopted wholesale, changed, or ignored by a person defining an information system implementation.
+Use of set-parameter in this context, sets the parameter for the referenced control and any associated statements.
A reference to the specific implemented statement associated with a control.
+control statement in the source OSCAL instance is sufficient to reference the data item locally or globally (e.g., in an imported OSCAL instance).Since responsible-role associates multiple party-uuid entries with a single role-id, each role-id must be referenced only once.
While a part is not required to have an id, it is often desirable for an identifier to be provided, which allows the part to be referenced elsewhere in OSCAL document instances. For this reason, it is RECOMMENDED to provide a part identifier.
+ns.name. This allows different organizations to associate distinct semantics with the same name.This value must be an absolute URI that serves as a naming system identifier.
+When a ns is not provided, its value should be assumed to be http://csrc.nist.gov/ns/oscal and the name should be a name defined by the associated OSCAL model.
name, or a category to which the part belongs.One use of this flag is to distinguish or discriminate between the semantics of multiple parts of the same control with the same name and ns (since even within a given namespace it can be useful to overload a name).
A class can be used in validation rules to express extra constraints over named items of a specific class value.
A class can also be used in an OSCAL profile as a means to target an alteration to control content.
A part provides for logical partitioning of prose, and can be thought of as a grouping structure (e.g., section). A part can have child parts allowing for arbitrary nesting of prose content (e.g., statement hierarchy). A part can contain prop objects that allow for enriching prose text with structured name/value information.
A part can be assigned an optional id, which allows references to this part from within a catalog, or within an instance of another OSCAL model that has a need to reference the part. Examples of where part referencing is used in OSCAL include:
Use of part and prop provides for a wide degree of extensibility within the OSCAL catalog model. The optional ns provides a means to qualify a part's name, allowing for organization-specific vocabularies to be defined with clear semantics. Any organization that extends OSCAL in this way should consistently assign a ns value that represents the organization, making a given namespace qualified name unique to that organization. This allows the combination of ns and name to always be unique and unambiguous, even when mixed with extensions from other organizations. Each organization is responsible for governance of their own extensions, and is strongly encouraged to publish their extensions as standards to their user community. If no ns is provided, the name is expected to be in the "OSCAL" namespace.
To ensure a ns is unique to an organization and naming conflicts are avoided, a URI containing a DNS or other globally defined organization name should be used. For example, if FedRAMP and DoD both extend OSCAL, FedRAMP will use the ns
+ http://fedramp.gov/ns/oscal, while DoD might use the ns
+ https://defense.gov for any organization specific name.
Tools that process OSCAL content are not required to interpret unrecognized OSCAL extensions; however, OSCAL compliant tools should not modify or remove unrecognized extensions, unless there is a compelling reason to do so, such as data sensitivity.
+A class can be used in validation rules to express extra constraints over named items of a specific class value.
value if no value is assigned.The label value is intended use when rendering a parameter in generated documentation or a user interface when a parameter is referenced. Note that labels are not required to be distinctive, which means that parameters within the same control may have the same label.
+A set of values provided in a catalog can be redefined in OSCAL's profile or system-security-plan models.
The OSCAL parameter value construct can be used to prescribe a specific parameter value in a catalog or profile. In cases where a prescriptive value is not possible in a catalog or profile, it may be possible to constrain the set of possible values to a few options. Use of select in a parameter instead of value is a way of defining value options that may be set.
A set of allowed parameter values expressed as a set of options which may be selected. These options constrain the permissible values that may be selected for the containing parameter. When the value assignment is made, such as in an OSCAL profile or system security plan, the actual selected value can be examined to determine if it matches one of the permissible choices for the parameter value.
+When the value of how-many is set to "one-or-more", multiple values may be assigned reflecting more than one choice.
In a catalog, a parameter is typically used as a placeholder for the future assignment of a parameter value, although the OSCAL model allows for the direct assignment of a value if desired by the control author. The value may be optionally used to specify one or more values. If no value is provided, then it is expected that the value will be provided at the Profile or Implementation layer.
A parameter can include a variety of metadata options that support the future solicitation of one or more values. A label provides a textual placeholder that can be used in a tool to solicit parameter value input, or to display in catalog documentation. The desc provides a short description of what the parameter is used for, which can be used in tooling to help a user understand how to use the parameter. A constraint can be used to provide criteria for the allowed values. A guideline provides a recommendation for the use of a parameter.
A set of parameter value choices, that may be picked from to set the parameter value.
+id value. When referencing an externally defined control, the Control Identifier Reference must be used in the context of the external / imported OSCAL instance (e.g., uri-reference).This element provides an alternative to calling controls individually from a catalog.
+If with-child-controls is yes
on the call to a control, no sibling callelements need to be used to call any controls appearing within it. Since generally, this is how control enhancements are represented (as controls within controls), this provides a way to include controls with all their dependent controls (enhancements) without having to call them individually.
component can be used to reference the data item locally or globally (e.g., in an imported OSCAL instance). This UUID should be assigned per-subject, which means it should be consistently used to identify the same subject across revisions of the document.Used for service components to define the protocols supported by the service.
component in a component-definition that originally defined the component.Since responsible-role associates multiple party-uuid entries with a single role-id, each role-id must be referenced only once.
Components may be products, services, application programming interface (APIs), policies, processes, plans, guidance, standards, or other tangible items that enable security and/or privacy.
+The type indicates which of these component types is represented.
When defining a service component where are relationship to other components is known, one or more link entries with rel values of provided-by and used-by can be used to link to the specific component identifier(s) that provide and use the service respectively.
service protocol can be used to reference the data item locally or globally (e.g., in an imported OSCAL instance). This UUID should be assigned per-subject, which means it should be consistently used to identify the same subject across revisions of the document.The short name of the protocol (e.g., https).
+Should be a number within a permitted range
+Should be a number within a permitted range
+To be validated as a natural number (integer >= 1). A single port uses the same value for start and end. Use multiple 'port-range' entries for non-contiguous ranges.
+system user can be used to reference the data item locally or globally (e.g., in an imported OSCAL instance). This UUID should be assigned per-subject, which means it should be consistently used to identify the same subject across revisions of the document.Permissible values to be determined closer to the application, such as by a receiving authority.
+inventory item can be used to reference the data item locally or globally (e.g., in an imported OSCAL instance). This UUID should be assigned per-subject, which means it should be consistently used to identify the same subject across revisions of the document.component that is implemented as part of an inventory item.This construct is used to either: 1) associate a party or parties to a role defined on the component using the responsible-role construct, or 2) to define a party or parties that are responsible for a role defined within the context of the containing inventory-item.
+
Since responsible-party associates multiple party-uuid entries with a single role-id, each role-id must be referenced only once.
Since responsible-party associates multiple party-uuid entries with a single role-id, each role-id must be referenced only once.
control statement.system identification, the system identification must be used in the context of the external / imported OSCAL instance (e.g., uri-reference). This string should be assigned per-subject, which means it should be consistently used to identify the same system across revisions of the document.http://fedramp.gov/ns/oscal instead.http://datatracker.ietf.org/doc/html/rfc4122 instead.http://datatracker.ietf.org/doc/html/rfc4122 instead.This value must be an absolute URI that serves as a naming system identifier.
+parameter within a control, who's catalog has been imported into the current implementation context.
+ mapping can be used to reference the data item locally or globally (e.g., in
+ an imported OSCAL instance). This UUID should be assigned
+ per-subject, which means it should be consistently used to identify the same
+ mapping across revisions of the document.This value must be an absolute + URI that serves as a naming + system identifier.
+When a ns is not provided, its value should be assumed to be
+ http://csrc.nist.gov/ns/oscal and the name should be a name defined by
+ the associated OSCAL model.
matching-rationale method globaly
+ defined in the provenance unless overwritten locally in the
+ map. The relationship type and the matching-rationale
+ must be used together. However, more than one matching-rationale
+ method may apply to a source and target pair. source and target
+ requirements are similar, although not necessarily identical. The words
+ may differ, but both mapped sets convey similar information with the
+ same effective meaning. This relationship may be reversed, since `A
+ equivalent-to B` also means that `B equivalent-to A`. This relationship
+ is less suitable for a syntactic
+ matching-rationale
+ .source and target
+ requirements are the same. Differences in capitalization, spelling, and
+ grammar can be ignored, if these differences do not change the meaning.
+ This relationship may be reversed, since `A equal-to B` also means that
+ `B equal-to A`.source requirements are a subset of
+ target requirements. In other words, target contains
+ all sourcerequirements and aditional others. This
+ relationship may be reversed as a `superset-of`, since `A subset-of B`
+ also means that `B superset-of A`.source requirements are a
+ superset of target requirements. In other words,
+ source contains all targetrequirements and aditional
+ others. This relationship may be reversed as a `subset-of`, since `A
+ superset-of B` also means that `B subset-of A`.source and target
+ requirements have some overlap, but each includes content that the other
+ does not. This relationship may be reversed, since `A intersects-with B`
+ also means that `B intersects-with A`. A mapping at statement level
+ could result on relationships mapping that allows for more
+ inference than using this relationship type.source and target
+ requirements are not related; their content does not overlap. This
+ relation is introduced not with the intention to support exhaustiv
+ mapping of all requirements and statements that have no overlap, but
+ rather to support edge cases such is the need to tailor a
+ relationship in the context of a component or system to better
+ align with the implementation and configuration of the respective
+ component or system. Also, this relationship is provided in
+ support of the NIST IR
+ 8477.For example, consider the CSF 1.1's PR.AC-1, "Identities and credentials are + issued, managed, verified, revoked, and audited for authorized devices, + users and processes", and the Privacy Framework's PR.AC-P1, "Identities and + credentials are issued, managed, verified, and devices."
+These two requirements have identical wording except for "users” versus + “individuals” and the order of the last few words. With a + `matching-rationale` of syntactic, the relationship type would beintersects + with because the two overlap, but each includes content that the other does + not. However, with a rationale of semantic, the relationship type would be + equal if “users” and “individuals” have the same meaning in their respective + sources, subset if “users” was a subset of “individuals,” and so on.
+When establishing relationships, mapping SHOULD be done at the control + statement level where possible. This approach allows for a more accurate + relationship.
+type
+ .type. This value must be an absolute URI that serves as a naming system identifier.
+When a ns is not provided, its value should be assumed to be http://csrc.nist.gov/ns/oscal and the type should be a type defined by the associated OSCAL model.
The type value must be interpreted in the context of the
+ associated ns value.
When a ns is not provided, its value should be assumed to be http://csrc.nist.gov/ns/oscal
+ and this type should be set to one of the OSCAL defined values.
This value may be one of:
+back-matter
+ resource in this or an imported document (see linking
+ to another OSCAL object).
+ mapping-collection. If a control is partially mapped, the parts of the control
+ are not mappable, the gap and discrepancies should be documented in the
+ relationship-gal. SSP
+ can be used to reference the data item locally or globally (e.g., in an imported
+ OSCAL instance).This UUID should be assigned
+ per-subject, which means it should be consistently used to identify the same
+ subject across revisions of the document.If with-child-controls is yes
on the call to a control,
+ any controls appearing within it (child controls) will be selected, with no
+ additional call directives required. This flag provides a way
+ to include controls with all their dependent controls (enhancements) without
+ having to call them individually.
This field is scoped - that is, it can be used at the document-level, the mapping level, or the individual map item level. It only applies to targets and sources within it's scope.
+Coverage is calculated by taking the full set of all targets in-scope and the full set of all sources in-scope, then applying the "generation-method" to the two sets. + By default the method is an arbitrary estimation of coverage.
+In a general sense "coverage" is defined as the percent of the set of targets that have mapped to by the set of sources, + where each map is an "equivalent-to" or "equal-to" valued "relationship". Where relationship is "subset-of" or otherwise, it counts as an appropriate fraction of a full map.
+Since coverage is derived from mapping relationships, it is defined in the context of the mapping's "matching-rationale" - that is, the method used to determine relationships.
+The value of this field applies to the entire document if found in the top-level + mapping provenance, otherwise it applies to the specific mapping in which it is found.
+If this field appears in both locations, the lower-scoped value overrides while within it's scope.
+The value of this flag applies to the entire document if found in the top-level + mapping provenance, otherwise it applies to the specific mapping in which it is found.
+If this flag appears in both locations, the lower-scoped value overrides while within it's scope.
+The value of this flag applies to the entire document if found in the top-level + mapping provenance, otherwise it applies to the specific mapping in which it is found.
+If this flag appears in both locations, the lower-scoped value overrides while within it's scope.
+The value of this flag applies to the entire document if found in the top-level + mapping provenance, otherwise it applies to the specific mapping in which it is found.
+If this flag appears in both locations, the lower-scoped value overrides while within it's scope.
+The OSCAL Control mapping format can be used to describe how a collection of security controls and related control enhancements relate to another collection of controls. The root of the Control Catalog format is mapping-collection.
+
Back matter including references and resources.
+A mapping collection affirmatively declares the relationships that exist between sets of controls and/or control statements in a source and target. It is expected that inferences can be made based on what is mapped; however, no inferences should be made based on what is not mapped, since it is impossible to quantify how complete or granular a given mapping is.
+While published, last-modified, and oscal-version are not required, values for these entries should be provided if the information is known. A link with a rel of source
should be provided if the information is known.
Permissible values to be determined closer to the application (e.g. by a receiving authority).
+OSCAL has defined a set of standardized roles for consistent use in OSCAL documents. This allows tools consuming OSCAL content to infer specific semantics when these roles are used. These roles are documented in the specific contexts of their use (e.g., responsible-party, responsible-role). When using such a role, it is necessary to define these roles in this list, which will then allow such a role to be referenced.
+The physical address of the location, which will provided for physical locations. Virtual locations can omit this data item.
+A contact email associated with the location.
+A phone number used to contact the location.
+This data field is deprecated in favor of using a link with an appropriate relationship.
+class can be used to indicate the sub-type of data-center as primary or alternate.An address might be sensitive in nature. In such cases a title, mailing address, email-address, and/or phone number may be used instead.
+person individuals with a specific purpose.This value must be an absolute URI that serves as a naming system identifier.
+This is a contact email associated with the party.
+A phone number used to contact the party.
+party by UUID, typically an organization, that this subject is associated with.Since the reference target of an organizational affiliation must be another party (whether further qualified as person or organization) as indicated by its uuid. As a machine-oriented identifier with uniqueness across document and trans-document scope, this uuid value is sufficient to reference the data item locally or globally across related documents, e.g., in an imported OSCAL instance.
Parties of both the person or organization type can be associated with an organization using the member-of-organization.
A party can be optionally associated with either an address or a location. While providing a meaningful location for a party is desired, there are some cases where it might not be possible to provide an exact location or even any location.
+Since responsible-party associates multiple party-uuid entries with a single role-id, each role-id must be referenced only once.
The combination of scheme and the field value must be unique.
All OSCAL documents use the same metadata structure, that provides a consistent way of expressing OSCAL document metadata across all OSCAL models. The metadata section also includes declarations of individual objects (i.e., roles, location, parties) that may be referenced within and across linked OSCAL documents.
+The metadata in an OSCAL document has few required fields, representing only the bare minimum data needed to differentiate one instance from another. Tools and users creating OSCAL documents may choose to use any of the optional fields, as well as extension mechanisms (e.g., properties, links) to go beyond this minimum to suit their use cases.
+A publisher of OSCAL content can use the published, last-modified, and version fields to establish information about an individual in a sequence of successive revisions of a given OSCAL-based publication. The metadata for a previous revision can be represented as a revision within this object. Links may also be provided using the predecessor-version and successor-version link relations to provide for direct access to the related resource. These relations can be provided as a link child of this object or as link within a given revision.
A responsible-party entry in this context refers to roles and parties that have responsibility relative to the production, review, publication, and use of the containing document.
This value may be either:
+href, which can be used to verify the resource was not changed since it was hashed.The hash value can be used to confirm that the resource referenced by the href is the same resources that was hashed by retrieving the resource, calculating a hash, and comparing the result to this value.
Multiple rlink objects can be included for a resource. In such a case, all provided rlink items are intended to be equivalent in content, but may differ in structure or format.
A media-type is used to identify the format of a given rlink, and can be used to differentiate items in a collection of rlinks. The media-type provides a hint to the OSCAL document consumer about the structure of the resource referenced by the rlink.
+
resource. This is the name that will be assigned to the file when the file is decoded.rlink or base64 object.filename.title is required when a citation is provided.A resource can be used in two ways. 1) it may point to an specific retrievable network resource using a rlink, or 2) it may be included as an attachment using a base64. A resource may contain multiple rlink and base64 entries that represent alternative download locations (rlink) and attachments (base64) for the same resource.
Both rlink and base64 allow for a media-type to be specified, which is used to distinguish between different representations of the same resource (e.g., Microsoft Word, PDF). When multiple rlink and base64 items are included for a given resource, all items must contain equivalent information. This allows the document consumer to choose a preferred item to process based on a the selected item's media-type. This is extremely important when the items represent OSCAL content that is represented in alternate formats (i.e., XML, JSON, YAML), allowing the same OSCAL data to be processed from any of the available formats indicated by the items.
When a resource includes a citation, then the title and citation properties must both be included.
Provides a collection of identified resource objects that can be referenced by a link with a rel value of "reference" and an href value that is a fragment "#" followed by a reference to a reference's uuid. Other specialized link "rel" values also use this pattern when indicated in that context of use.
The following is a contrived example to show the use of link, citation, and resource.
+This value must be an absolute URI that serves as a naming system identifier.
+When a ns is not provided, its value should be assumed to be http://csrc.nist.gov/ns/oscal and the name should be a name defined by the associated OSCAL model.
name.This can be used to further distinguish or discriminate between the semantics of multiple properties of the same object with the same name and ns, or to group properties into categories.
A class can be used in validation rules to express extra constraints over named items of a specific class value. It is available for grouping, but unlike group is not expected specifically to designate any group membership as such.
Different sets of properties may relate to separate contexts. Declare a group on a property to associate it with one or more other properties in a given context.
+Properties permit the deployment and management of arbitrary controlled values, within OSCAL objects. A property can be included for any purpose useful to an application or implementation. Typically, properties will be used to sort, filter, select, order, and arrange OSCAL content objects, to relate OSCAL objects to one another, or to associate an OSCAL object to class hierarchies, taxonomies, or external authorities. Thus, the lexical composition of properties may be constrained by external processes to ensure consistency.
+Property allows for associated remarks that describe why the specific property value was applied to the containing object, or the significance of the value in the context of the containing object.
+This value may be one of:
+back-matter resource by UUID expressed as a bare URI fragment.The media-type provides a hint about the content model of the referenced resource. A valid entry from the IANA Media Types registry SHOULD be used.
href points to a back-matter/resource, this value will indicate the URI fragment to append to any rlink associated with the resource. This value MUST be URI encoded.Since both link and back-matter/resource both allow specification of a media-type, the media-type on link may conflict with the any media-type entries on a resource's rlink or base64 objects. This constraint prevents this from occurring.
This pattern is based on the fragment Augmented Backus-Naur form (ABNF) syntax provided in [RFC3986 section 3.5](https://www.rfc-editor.org/rfc/rfc3986#section-3.5). Uppercase alpha hex digits are required, which is the preferred normalized form defined in RFC3986.
+To provide a cryptographic hash for a remote target resource, a local reference to a back matter resource is needed. The resource allows one or more hash values to be provided using the rlink/hash object.
The OSCAL link is a roughly based on the HTML link element.
+
The following is a contrived example to show the use of link, citation, and resource.
+role performed by a party.role.A responsible-party requires one or more party-uuid references creating a strong relationship arc between the referenced role-id and the reference parties. This differs in semantics from responsible-role which doesn't require that a party-uuid is referenced.
The scope of use of this object determines if the responsibility has been performed or will be performed in the future. The containing object will describe the intent.
+Provides a means to segment the value space for the type, so that different organizations and individuals can assert control over the allowed action's type. This allows the semantics associated with a given type to be defined on an organization-by-organization basis.
An organization MUST use a URI that they have control over. e.g., a domain registered to the organization in a URI, a registered uniform resource names (URN) namespace.
+role performed.role.A responsible-role allows zero or more party-uuid references, each of which creates a relationship arc between the referenced role-id and the referenced party. This differs in semantics from responsible-party, which requires that at least one party-uuid is referenced.
The scope of use of this object determines if the responsibility has been performed or will be performed in the future. The containing object will describe the intent.
+Any other value used MUST be a value defined in the W3C XML Security Algorithm Cross-Reference Digest Methods (W3C, April 2013) or RFC 6931 Section 2.1.5 New SHA Functions.
+The Internet Assigned Numbers Authority (IANA) Media + Types Registry defines a standardized set of media types, which may be used + here.
+The application/oscal+xml, application/oscal+json or application/oscal+yaml media types SHOULD be used when referencing OSCAL XML, JSON, or YAML resources respectively.
**Note: There is no official media type for YAML at this time.** OSCAL documents should specify application/yaml for general YAML content, or application/oscal+yaml for YAML-based OSCAL content. This approach aligns with use of a structured name suffix, per RFC 6838 Section 4.2.8.
Some earlier OSCAL content incorporated the model into the media type. For example: application/oscal.catalog+xml. This practice SHOULD be avoided, since the OSCAL model can be detected by parsing the initial content of the referenced resource.
The remarks field SHOULD not be used to store arbitrary data. Instead, a prop or link should be used to annotate or reference any additional data not formally supported by OSCAL.
Typically, this date value will be machine-generated at the time the containing document is published.
+In some cases, an OSCAL document may be derived from some source material provided in a different format. In such a case, the published value should indicate when the OSCAL document instance was last published, not the source material.
This value represents the point in time when the OSCAL document was last updated, or at the point of creation the creation date. Typically, this date value will be machine generated at time of creation or modification. Ideally, this field will be managed by the editing tool or service used to make modifications when storing the modified document.
+The intent of the last modified timestamp is to distinguish between significant change milestones when the document may be accessed by multiple entities. This allows a given entity to differentiate between multiple document states at specific points in time. It is possible to make multiple modifications to the document without storing these changes. In such a case, the last modified timestamp might not be updated until the document is finally stored.
+In some cases, an OSCAL document may be derived from some source material in a different format. In such a case, the last-modified value should indicate the last modification time of the OSCAL document instance, not the source material.
A version may be a release number, sequence number, date, or other identifier sufficient to distinguish between different document revisions.
+While not required, it is recommended that OSCAL content authors use Semantic Versioning as the version format. This allows for the easy identification of a version tree consisting of major, minor, and patch numbers.
+A version is typically set by the document owner or by the tool used to maintain the content.
+Indicates the version of the OSCAL model to which the document conforms, for example 1.1.0
or 1.0.0-milestone1
. That can be used as a hint for a tool indicating which version of the OSCAL XML or JSON schema to use for validation.
The OSCAL version serves a different purpose from the document version and is used to represent a different concept. If both have the same value, this is coincidental.
+Providing a country code provides an international means to interpret the phone number.
+scheme.This value must be an absolute URI that serves as a naming system identifier.
+A document identifier provides a globally unique identifier with a cross-instance scope that is used for a group of documents that are to be treated as different versions, representations or digital surrogates of the same document.
+A document identifier provides an additional data point for identifying a document that can be assigned by a publisher or organization for purposes in a wider system, such as a digital object identifier (DOI) or a local content management system identifier.
+Use of a document identifier allows for document creators to associate sets of documents that are related in some way by the same document-id.
An OSCAL document always has an implicit document identifier provided by the document's UUID, defined by the uuid on the top-level object. Having a default UUID-based identifier ensures all documents can be minimally identified when other document identifiers are not provided.
The OSCAL Plan of Action and Milestones (POA&M) format is used to describe the information typically provided by an assessor during the preparation for an assessment.
+The root of the OSCAL Plan of Action and Milestones (POA&M) format is plan-action-milestones.
+
Used by the POA&M to import information about the system.
+Either an OSCAL-based SSP must be imported, or a unique system-id must be specified. Both may be present.
+Used to add any components, not defined via the System Security Plan (AR->AP->SSP)
+Used to add any inventory-items, not defined via the System Security Plan (AR->AP->SSP)
+Specifies components or assessment-platforms used in the assessment.
+Since multiple component entries can be provided, each component must have a unique uuid.
Used to identify the individual and/or tool generated this poam-item.
+In OSCAL a profile represents a set of selected controls from one or more control catalogs. Such a set of controls can + be referenced by an OSCAL system security plan (SSP) to establish a control baseline. This effective set of controls is produced from an OSCAL + profile using a deterministic, predictable process called profile resolution.
+A profile references one or more OSCAL catalogs or profiles to import controls for control selection and tailoring. A profile can also describe how a resulting catalog is structured. When the profile is resolved, these selections and modifications are processed to produce a resulting OSCAL catalog.
+OSCAL profiles have uses beyond establishing control baselines, such as documentation + generation or as reference tables for validations.
+profile
+ element.An OSCAL document that describes a tailoring of controls from one or more catalogs, with possible modification of multiple controls. It provides mechanisms by which controls may be selected (import), merged or (re)structured (merge), and amended (modify). OSCAL profiles may select subsets of controls, set parameter values for them in application, and even adjust the representation of controls as given in and by a catalog. They may also serve as sources for further modification in and by other profiles, that import them.
This value may be one of:
+back-matter resource in this or an imported document (see linking to another OSCAL object).Identifies that all controls are to be included from the imported catalog or profile.
+If with-child-controls is yes
on the call to a control, any controls appearing within it (child controls) will be selected, with no additional call directives required. This flag provides a way to include controls with all their dependent controls (enhancements) without having to call them individually.
Identifies which controls to exclude, or eliminate, from the set of included controls by control identifier or match pattern.
+The contents of the import element indicate which controls from the source will be included. Controls from the source catalog or profile may be either selected, using the include-all or include-controls directives, or de-selected (using an exclude-controls directive).
The custom element represents a custom arrangement or organization of controls in the resolution of a catalog. This structuring directive gives the profile author the ability to define an entirely different organization of controls as compared to their source catalog(s).
This optional data element is available to support hyperlinking to formal groups or families as defined in control catalogs, among other operations.
+A class can be used in validation rules to express extra constraints over named items of a specific class value.
A class can also be used in an OSCAL profile as a means to target an alteration to control content.
This construct mirrors the same construct that exists in an OSCAL catalog.
+A class can be used in validation rules to express extra constraints over named items of a specific class value.
value if no value is assigned.The label value should be suitable for inline display in a rendered catalog.
+Used to (re)define a parameter value.
+class.id.title or
+ prop.ns, which is the namespace associated with a part, or prop.Use by-name, by-class, by-id or by-item-name to indicate class tokens or ID reference, or the formal name, of the component to be removed or erased from a control, when a catalog is resolved. The control affected is indicated by the pointer on the removal's parent (containing) alter element.
To change an element, use remove to remove the element, then add to add it back again with changes.
When no by-id is given, the addition is inserted into the control targeted by the alteration at the start or end as indicated by position. Only position values of "starting" or "ending" are permitted when there is no by-id.
+ by-id, when given, should indicate, by its ID, an element inside the control to serve as the anchor point for the addition. In this case, position value may be any of the permitted values.
Use @control-id to indicate the scope of alteration.
It is an error for two alter elements to apply to the same control. In practice, multiple alterations can be applied (together), but it creates confusion.
At present, no provision is made for altering many controls at once (for example, to systematically remove properties or add global properties); extending this element to match multiple control IDs could provide for this.
+Since multiple set-parameter entries can be provided, each parameter must be set only once.
Identifies which controls to exclude, or eliminate, from the set of matching includes.
+To be schema-valid, this element must contain either (but not both) a single include-all directive, or a sequence of include-controls directives.
If this directive is not provided, then no controls are to be inserted; i.e., all controls are included explicitly.
+The OSCAL Control SSP format can be used to describe the information typically specified in a system security plan, such as those defined in NIST SP 800-18.
+The root of the OSCAL System Security Plan (SSP) format is system-security-plan.
SSP can be used to reference the data item locally or globally (e.g., in an imported OSCAL instance).This UUID should be assigned per-subject, which means it should be consistently used to identify the same subject across revisions of the document.This value may be one of:
+back-matter resource in this or an imported document (see linking to another OSCAL object).If the resource is an OSCAL profile, it is expected that a tool will resolve the profile according to the OSCAL profile resolution specification to produce a resolved profile for use when processing the containing system security plan. This allows a system security plan processor to use the baseline as a catalog of controls.
+While it is possible to reference a previously resolved OSCAL profile as a catalog, this practice is discouraged since the unresolved form of the profile communicates more information about selections and changes to the underlying catalog. Furthermore, the underlying catalog can be maintained separately from the profile, which also has maintenance advantages for distinct maintainers, ensuring that the best available information is produced through profile resolution.
+Since system-name-short is optional, if the system-name-short is not provided, the system-name can be used as a substitute.
Often, organizations require the security sensitivity level to correspond with the highest confidentiality, integrity, or availability level identified by security-impact-level.
+
The hybrid cloud deployment model, as defined by The NIST Definition of Cloud Computing, can be supported by selecting two or more of the existing deployment models.
+Since responsible-party associates multiple party-uuid entries with a single role-id, each role-id must be referenced only once.
information type can be used to reference the data item locally or globally (e.g., in an imported OSCAL instance). This UUID should be assigned per-subject, which means it should be consistently used to identify the same subject across revisions of the document.system used, such as NIST SP 800-60.This value must be an absolute URI that serves as a naming system identifier.
+system used, such as NIST SP 800-60. This identifier has cross-instance scope and can be used to reference this system elsewhere in this or other OSCAL instances. This id should be assigned per-subject, which means it should be consistently used to identify the same subject across revisions of the document.FIPS-199 taxonomy is provided here as a starting point. We will provide other taxonomies based on community requests.
+If 'other' is selected, a remark must be included to describe the current state.
+A visual depiction of the system's authorization boundary.
+A given uuid must be assigned only once to a diagram.
diagram can be used to reference the data item locally or globally (e.g., in an imported OSCAL instance). This UUID should be assigned per-subject, which means it should be consistently used to identify the same subject across revisions of the document.This description is intended to be used as alternate text to support compliance with requirements from Section 508 of the United States Workforce Rehabilitation Act of 1973. +
+A diagram must include a link with a rel value of "diagram", who's href references a remote URI or an internal reference within this document containing the diagram.
The internal reference "#diagram1" points to an attached resource defined in the back-matter as a resource. The media-type indicates that the image is a Portable Network Graphics (PNG) image.
A given uuid must be assigned only once to a diagram.
A given uuid must be assigned only once to a diagram.
leveraged authorization can be used to reference the data item locally or globally (e.g., in an imported OSCAL instance). This UUID should be assigned per-subject, which means it should be consistently used to identify the same subject across revisions of the document.party that manages the leveraged system.A set of inventory-item entries that represent the managed inventory instances of the system.
A given uuid must be assigned only once to a user.
Since multiple set-parameter entries can be provided, each parameter must be set only once.
Use of set-parameter in this context, sets the parameter for all controls referenced by any implemented-requirement contained in this context. Any set-parameter defined in a child context will override this value. If not overridden by a child, this value applies in the child context.
control requirement can be used to reference the data item locally or globally (e.g., in an imported OSCAL instance). This UUID should be assigned per-subject, which means it should be consistently used to identify the same subject across revisions of the document.control-origination prop defined in a child context will override the parent value.Since all implementation statements are defined at the by-component level (e.g., type=this-system), there must be at least one by-component.
+Since multiple set-parameter entries can be provided, each parameter must be set only once.
Since responsible-role associates multiple party-uuid entries with a single role-id, each role-id must be referenced only once.
Since statement entries can be referenced using the statement's statement-id, each statement must be referenced only once.
Since by-component can reference component entries using the component's uuid, each component must be referenced only once. This ensures that all implementation statements are contained in the same by-component entry.
Use of set-parameter in this context, sets the parameter for the referenced control. Any set-parameter defined in a child context will override this value. If not overridden by a child, this value applies in the child context.
A reference to the specific implemented statement associated with a control.
+control statement in the source OSCAL instance is sufficient to reference the data item locally or globally (e.g., in an imported OSCAL instance).Since responsible-role associates multiple party-uuid entries with a single role-id, each role-id must be referenced only once.
Since by-component can reference component entries using the component's uuid, each component must be referenced only once. This ensures that all implementation statements are contained in the same by-component entry.
component that is implementing a given control.by-component entry can be used to reference the data item locally or globally (e.g., in an imported OSCAL instance). This UUID should be assigned per-subject, which means it should be consistently used to identify the same subject across revisions of the document.The implementation-status is used to qualify the status value to indicate the degree to which the control is implemented.
provided entry can be used to reference the data item locally or globally (e.g., in an imported OSCAL instance). This UUID should be assigned per-subject, which means it should be consistently used to identify the same subject across revisions of the document.Since responsible-role associates multiple party-uuid entries with a single role-id, each role-id must be referenced only once.
responsibility can be used to reference the data item locally or globally (e.g., in an imported OSCAL instance). This UUID should be assigned per-subject, which means it should be consistently used to identify the same subject across revisions of the document.A role defined at the by-component level takes precedence over the same role defined on the parent implemented-requirement or on the referenced component.
+Since responsible-role associates multiple party-uuid entries with a single role-id, each role-id must be referenced only once.
inherited control implementation can be used to reference the data item locally or globally (e.g., in an imported OSCAL instance). This UUID should be assigned per-subject, which means it should be consistently used to identify the same subject across revisions of the document.Since responsible-role associates multiple party-uuid entries with a single role-id, each role-id must be referenced only once.
control implementation can be used to reference the data item locally or globally (e.g., in an imported OSCAL instance). This UUID should be assigned per-subject, which means it should be consistently used to identify the same subject across revisions of the document.Since responsible-role associates multiple party-uuid entries with a single role-id, each role-id must be referenced only once.
component in a component-definition that originally described the component this component was based on.by-component object that is used as evidence of implementation.Since multiple set-parameter entries can be provided, each parameter must be set only once.
Use of set-parameter in this context, sets the parameter for the control referenced in the containing implemented-requirement applied to the referenced component. If the by-component is used as a child of a statement, then the parameter value also applies only in the context of the referenced statement. If the same parameter is also set in the control-implementation or a specific implemented-requirement, then this by-component/set-parameter value will override the other value(s) in the context of the referenced component, control, and statement (if parent).