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 integrates with the Open Security Controls Assessment Language (OSCAL), a standardized machine-readable format developed by NIST that facilitates interoperability, consistency, and automation in IT security control assessments, compliance reporting, and risk management. CAM supports OSCAL version 1.1.2 and exclusively uses JSON format. It enables ServiceNow customers to import and export OSCAL data across multiple security models, streamlining security control management and compliance processes.

    Show full answer Show less

    Supported OSCAL Models in CAM

    • Catalog: Provides a structured representation of control catalogs including control objectives, requirements, test templates, and assessment procedures. CAM maps these controls precisely to NIST standards, allowing detailed control information management. It also supports overlay catalogs containing additional policy controls outside of NIST.
    • Profile: Represents a baseline of selected controls derived from catalogs and overlays, including baseline controls auto-populated based on impact and information type of the authorization package. It supports inclusion and exclusion (Not Applicable) of controls for tailored baselines.
    • System Security Plan (SSP): Enables expression of system control implementations within a baseline or profile context. Key concepts include authorization boundaries for system scope, authorization packages aligned with NIST RMF steps, impact-based information types, and control states distinguishing inherited and hybrid controls.

    Import and Export Capabilities

    CAM supports comprehensive import and export of OSCAL data types relevant to security control lifecycle management:

    • Export: CAM exports data in OSCAL formats for Catalog, Profile, SSP, Assessment Plan (AP), Assessment Results (AR), and Plan of Action and Milestones (POA&M), utilizing defined field mappings to maintain data integrity and compatibility.
    • Import: CAM offers a playbook-style import experience to efficiently integrate OSCAL security control data, enhancing automation and reducing manual effort in control data management.

    Customization and Tailoring

    CAM utilizes OSCAL custom properties with unique namespaces to capture specific information, tailor content, and reflect impact values across all supported models. This capability allows organizations to extend OSCAL data to meet their unique security control and compliance requirements while maintaining standardization.

    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.