CAM OSCAL

  • Release version: Australia
  • Updated March 12, 2026
  • 2 minutes to read
    • Summarize
    Summarized using AI
    This content was generated using new OpenAI-powered functionality. Results are provided on an as is basis and are not guaranteed to be accurate or complete.

    Summary of CAM OSCAL

    CAM OSCAL enables ServiceNow customers to use the Open Security Controls Assessment Language (OSCAL) standard, developed by NIST, for expressing security control-related information in a consistent, interoperable, and machine-readable JSON format. This capability supports automation in security control assessments, compliance reporting, and risk management processes, specifically supporting OSCAL version 1.1.2.

    Show full answer Show less

    Supported OSCAL Models in CAM

    CAM supports importing and exporting OSCAL data for several key models:

    • Catalog: Represents a structured catalog of controls, including control objectives, their requirements, test templates, and assessment procedures. It also supports overlay catalogs with additional policies not part of NIST but relevant for authorization packages.
    • Profile: Defines a baseline of selected controls from catalogs and overlays, including baseline controls auto-populated based on impact level, controls included in the authorization package, and controls marked as Not Applicable.
    • System Security Plan (SSP): Describes the implementation of controls within an information system, including elements such as authorization boundary, authorization package, information type (impact level), and control states (implemented, inherited, or hybrid).
    • Assessment Plan (AP) and Assessment Results (AR): CAM supports exporting engagement and control test data into these standardized formats to facilitate assessment workflows.

    Practical Benefits for ServiceNow Customers

    • Standardization: CAM’s OSCAL support ensures security control data is captured and shared in a consistent, machine-readable format aligned with NIST standards.
    • Automation: Enables streamlined security control assessments, compliance reporting, and risk management through automated data exchange.
    • Interoperability: Facilitates integration with other security tools and frameworks that support OSCAL, enhancing data sharing and collaboration.
    • Customization: CAM uses a unique OSCAL namespace for custom properties, allowing tailored impact assessments and control adjustments within the platform.
    • Enhanced Security Governance: By supporting detailed modeling of control objectives, baselines, and system implementations, CAM helps manage authorization packages effectively across the Risk Management Framework.

    Using CAM OSCAL

    ServiceNow customers can import security control data using a guided playbook experience, simplifying the integration of OSCAL content. Export capabilities allow CAM users to generate OSCAL-compliant Catalogs, Profiles, SSPs, Assessment Plans, and Assessment Results, facilitating compliance evidence sharing and audit readiness.

    Open Security Controls Assessment Language (OSCAL) provides a standardized way to express control-related information, enabling interoperability, consistency, and automation in IT security. It supports the JSON format only. CAM supports OSCAL version 1.1.2.

    OSCAL is a set of machine-readable formats developed by the National Institute of Standards and Technology (NIST). It’s designed to support the automation of security control assessments, compliance reporting, and risk management processes.

    CAM supports the export and import of OSCAL data for both Catalog and System Security Plan (SSP) models.

    CAM supported OSCAL models

    CAM OSCAL supports the following models:
    Catalog
    According to NIST, the catalog model provides a structured, machine-readable representation of a catalog of controls. Therefore, as part of the catalog model, using CAM you can get the following control-related information:
    • Control objectives: These are mapped to controls. The Reference field in a control objective maps to the NIST control. The requirements of a control objective map to the statements of the NIST's control. Therefore, each part of the Description field in a control objective align with the sub-part of the NIST's control. The child control objectives of each control objective are mapped to the control field. Related control objectives of the control objective are mapped to the links field.
    • Control objective requirements: Statements or control requirements that are further broken down from a control objective's description.
    • Test templates: Tests done on controls. Each control has at least one test template, which has one assessment objective.
    • Assessment Procedures: These are assessment objectives of a test template or the tests done on controls.
    Overlay catalog
    Overlay controls: These are policies that consist of control objectives and are not part of NIST but can be in an authorization package.
    Profile
    According to NIST, the profile model provides a structured, machine-readable representation of a baseline. The profile model also represents a baseline of selected controls from one or more control catalogs.

    Baseline controls: Small set of control objectives that are auto-populated based on the impact. Impact is decided based on the Information Type of an authorization package.

    • Include-controls: These are baseline controls, which are part of the authorization package.
    • Exclude-controls: These are baseline controls that have been marked as Not Applicable.

    Profile consists of both Catalog and Overlay Catalog.

    System Security Plan (SSP)
    According to NIST, OSCAL SSP model enables a system owner to express the system implementation of an information system within the context of a specific baseline or OSCAL profile. Or, it represents a description of the control implementation of an information system.
    • Authorization boundary: An authorization boundary defines the scope of a particular system that can be continuously managed and monitored using the CAM application.
    • Authorization package: Created for the purpose of processing the assets or systems through the seven steps mandated by the RMF. For more information, see NIST RMF process overview.
    • Information type: Information type defines the impact level of the package, which is based on the criticality of the information system defined in the Categorize step.
    • Control: When control objectives move to Implementation state, they become controls.
    • Control requirement: When control objectives move to Implementation state, they become controls. Correspondingly, the control objective requirements convert to control requirement.
    • Inherited Control: Controls that are entirely inherited from parent authorization package. Then, it means that all the control requirements of each such control are also inherited completely.
    • Hybrid Control: These are partially inherited from the parent authorization package.