Continuous Control Monitoring

JupiterOne's Continuous Control Monitoring (CCM) provides enterprise teams with automated, graph-powered validation of security control effectiveness across your entire technology ecosystem.

Designed for organizations with existing governance frameworks and dedicated compliance programs, CCM helps Platform Engineering, DevOps, and Security Architecture teams continuously validate that controls defined in your governance systems are working as intended in your actual infrastructure.

Overview

Continuous Control Monitoring enables your team to:

• Automate control validation using JupiterOne's graph-powered query engine to continuously test control effectiveness
• Monitor control status in real-time across all your integrated cloud platforms, security tools, and IT infrastructure
• Map controls to multiple frameworks including CIS benchmarks for AWS, Azure, GCP, and other standards
• Detect configuration drift automatically as your infrastructure changes
• Visualize control health through dashboards showing compliance status and control test results
• Bridge the gap between governance requirements and actual infrastructure reality

The CCM Overview Dashboard provides an at-a-glance view of your control monitoring status, showing:

• Total Controls: Complete count of all controls being monitored
• Compliant Controls: Number of controls with all tests passing
• Non-Compliant Controls: Number of controls with one or more tests failing
• Compliance trends over time: Historical view of how control compliance changes
• Failing controls by account: Breakdown of which cloud accounts or integrations have the most issues

JupiterOne's Unified Control Framework:

JupiterOne uses CIS Controls v8.0 as the unified control list for all out-of-the-box content. All mappings between different security standards (SOC 2, CIS standards, NIST etc.) and JupiterOne-managed controls follow the CIS v8.0 mapping framework. This provides a consistent, industry-standard foundation for cross-framework control reuse and ensures that a single control implementation can satisfy requirements across multiple compliance standards.

Data Model

CCM uses a four-level hierarchy to organize your compliance and security program:

Framework
  └── Requirement
        └── Control
              └── Control Test

Level	What it answers	Owned by	Example
Framework	What standards do we follow?	External standards body or your organization	CIS v8, SOC 2, HIPAA, or an internal security policy
Requirement	What must we achieve?	The framework	"Maintain an inventory of enterprise assets"
Control	How do we meet the requirement?	Your organization	"Automated asset discovery via JupiterOne integrations"
Control Test	Is our control actually working?	Your organization	J1QL query: FIND aws_iam_user WITH mfaEnabled != true

A single control can satisfy multiple requirements across different frameworks, and each control can have multiple control tests for comprehensive validation.

Framework properties

Property	Description
Title	Name of the framework
Description	Overview of the framework's purpose and scope (markdown)

Requirement properties

Property	Description
Title	Name of the requirement
Identifier	Reference code from the framework (for example, "CC6.1" or "IDAM3.5"). Used for sorting and filtering.
Priority	Criticality level: Critical, High, Medium, or Low
Description	What the requirement mandates (markdown)

Control properties

Property	Description
Title	Name of the control
Identifier	Reference code for the control. Used for sorting and filtering.
Catalog	Logical grouping for the control (for example, "CIS Controls v8"). You can select an existing catalog or create a new one.
Owner	The JupiterOne user responsible for the control
State	Lifecycle state: Draft, Review, Live, or Retired
Description	What the control does and why it matters (markdown, AI-assisted on create)
Remediation	Steps to take when the control is failing (markdown, AI-assisted on create)
Exception Process	How to handle approved exceptions (markdown)

Control test properties

Property	Description
Title	Name of the test
Type	Whether results represent Compliant assets or Non-compliant assets
J1QL	The query that runs against your JupiterOne asset graph

View and Manage Modes

CCM has two modes that separate day-to-day monitoring from authoring workflows:

• View mode — Use this mode to review CCM results. You can browse frameworks, requirements, controls, and control test outcomes. This is the default mode for users who need to monitor compliance posture without making changes.
• Manage mode — Use this mode to author and edit frameworks, requirements, controls, and control tests. Switch to Manage mode when you need to create new content or modify existing definitions.

You can switch between modes using the toggle in the CCM navigation. View mode is read-only, so you cannot accidentally modify your control library while reviewing results.

note

View mode only displays Live controls and their results. Controls in Draft, Review, or Retired states are excluded from View mode counts and compliance metrics. Manage mode displays controls in all lifecycle states. This means framework control counts and compliance summaries will differ between the two modes.

How CCM Works

CCM's core capability is continuous, automated validation of control effectiveness using JupiterOne's query engine.

Automated Control Testing

How Control Tests Work:

1. Each control has one or more test definitions
2. Each test contains a J1QL query that runs against your asset graph
3. Tests execute automatically on a regular schedule
4. Control status updates based on whether all tests pass

Control Test Types

Each control test is either a Compliant assets test or a Non-compliant assets test. This determines how CCM interprets the query results.

Test type	What it returns	How CCM interprets results
Compliant assets	Resources that satisfy the control	Results are expected — the more, the better
Non-compliant assets	Resources that violate the control	Any results indicate a problem

Example Control Test:

A control for "Centralize Account Management" might have two tests:

• Test 1 (Non-compliant assets): Query for users WITHOUT SSO authentication — any results indicate a violation
• Test 2 (Compliant assets): Query for users WITH verified SSO — results confirm the control is working

Example Test Patterns:

• Non-compliant assets test: Find resources that violate the control

  FIND aws_s3_bucket WITH encrypted = false

• Compliant assets test: Verify required resources or configurations exist

  FIND aws_cloudtrail WITH enabled = true

Key Features

Control Inventory and Management

CCM provides centralized monitoring of all your security and IT controls. The Controls list page displays:

• Complete control inventory: Searchable and filterable list of all controls being monitored
• Real-time status: Current compliance state (Compliant/Non-Compliant/Not Configured) for each control
• Last evaluated timestamp: When each control was last tested
• Filtering options: Filter by status, lifecycle state, resource group, framework, or owner to focus on specific areas

Each control can be clicked to view detailed information including:

• Control tests: J1QL queries that validate whether the control is working
• Test results: Actual data showing what passed or failed
• Framework mappings: Which framework requirements this control satisfies

Viewing Control Test Results

When you click on a control, you can expand each test to see the J1QL query and actual results:

The control detail page shows:

• Control status: Overall status badge (Compliant/Non-Compliant)
• Test list: All tests defined for this control with individual pass/fail status
• J1QL queries: Click to expand any test to see the exact query being run
• Query results: Table view of actual assets that passed or failed the test
• Result count: Total number of resources affected (e.g., "1-41 of 41" accounts)

This detailed view enables you to:

• Investigate failures: See exactly which resources are violating the control
• Validate test logic: Review the J1QL query to ensure it's testing the right thing
• Collect evidence: Export query results for audit or remediation purposes
• Understand impact: Identify which accounts or resources need attention

Viewing Control Framework Mappings

Click the Requirements tab on any control detail page to see which framework requirements this control satisfies:

The Requirements tab shows:

• Framework name: Each framework the control maps to (e.g., "SOC 2 Trust Services Criteria", "CIS AWS Foundations Benchmark")
• Framework description: Brief overview of what the framework covers
• Specific requirement: The exact requirement within that framework (e.g., "CC6.1 | Logical and Physical Access Security")
• Edit Requirements button: Add or remove framework mappings for this control
• Remove buttons: Quickly unmap this control from a specific requirement

This view is useful for:

• Understanding control coverage: See which compliance requirements this control helps satisfy
• Managing mappings: Add this control to additional framework requirements or remove outdated mappings
• Cross-framework visibility: Identify controls that satisfy multiple standards simultaneously
• Audit preparation: Document which technical controls support each compliance requirement

Framework Management

Track control coverage across multiple security and compliance frameworks simultaneously:

The Frameworks page shows:

• All available frameworks: JupiterOne provides out-of-the-box CIS benchmarks including AWS, Azure, GCP, Microsoft 365, GitHub, Oracle Cloud Infrastructure, and Kubernetes, with additional frameworks available based on customer demand
• Total controls per framework: How many controls are defined for each framework
• Passing controls: How many controls are currently passing out of the total (for example, "6 passing out of 51")
• Framework descriptions: Overview of what each framework covers

note

If you need a framework that is not listed, click Request a new Framework on the framework selection page to submit a request. JupiterOne will prioritize framework additions based on customer demand and configure controls relevant to your specific integrations.

Clicking into any framework provides detailed information about:

• Framework requirements and their hierarchical structure
• Which controls map to each requirement
• Control test status for that specific framework
• Gaps where requirements lack control coverage

Framework Details

Click on any framework from the Frameworks page to view comprehensive details:

The framework detail page shows:

• Framework overview: Description and purpose of the framework
• Compliance metrics: Total controls, passing controls, and overall compliance percentage
• Requirements list: All requirements within the framework, organized hierarchically
• Control mappings: For each requirement, see which controls provide coverage
• Control status: Current pass/fail status for each mapped control
• Gap analysis: Quickly identify requirements that lack control coverage

Matrix View

Frameworks whose requirements are organized into two or more sections also get a Matrix tab on the framework detail page. The matrix lays the framework out as a grid — one column per section, one cell per requirement — so you can see where a framework is failing at a glance instead of scanning a list. For a tactic-and-technique framework such as MITRE ATT&CK, this is the familiar technique-matrix view.

Each cell is colored by the health of the requirement's controls, with the exact counts printed in the cell as a second channel alongside the color:

• Compliance lens (default): cells shade from green to red by the share of measured controls that are failing.
• Coverage lens: cells shade by how many of the requirement's controls are actually measured — answering "what do I detect?" rather than "what is failing?".
• Not measured: requirements whose controls have no test results yet render as dashed, uncolored cells in either lens.

Cells also carry markers for states worth spotting at a glance:

• Manual attestation: at least one control passes solely on a valid attestation (see Control Attestations)
• Draft: the requirement has controls in the draft lifecycle state
• Stale: a live control has not been evaluated in the last two days

Click any cell to open that requirement in the Requirements tab. Section columns are collapsible from their headers, which also show each section's passing/failing distribution.

Working with Frameworks

Understanding Control-to-Requirement Mapping

Controls in CCM can map to requirements across multiple frameworks. This allows you to:

• Reuse a single control definition across multiple compliance standards
• See which frameworks a control helps satisfy
• Understand the breadth of coverage provided by your control library
• Identify opportunities to consolidate duplicate controls

Creating and Managing Controls

Creating a New Control

To create a new control in CCM:

1. Navigate to a framework requirement in Manage mode
2. Click Add a control
3. Define the control properties:
   • Title: A clear, descriptive name for the control
   • Identifier: A reference code for sorting and filtering (for example, "IAM-001")
   • Catalog: A logical grouping (for example, "CIS Controls v8"). Select an existing catalog or create a new one.
   • Description: What the control validates and why it matters (JupiterOne AI can generate this from the title)
   • Remediation: Steps to take when the control is failing (JupiterOne AI can generate this)
   • Exception Process: How to handle approved exceptions for this control
   • Owner: The JupiterOne user responsible for maintaining and responding to this control
4. Map the control to framework requirements
5. Create control tests (J1QL queries) that validate the control

AI-Assisted Authoring

When you create a new control, JupiterOne AI can accelerate the process by generating content from your title:

1. Enter a descriptive title for your control
2. Click Draft control with AI — JupiterOne AI auto-generates the Description, Remediation steps, Identifier, and Source Catalog
3. Review and edit any generated field — AI suggestions are not mandatory

JupiterOne AI uses context from the linked requirement to improve the quality of its suggestions.

note

AI-assisted generation is available when creating a new control. When editing an existing control, you update fields manually.

Creating Control Tests

Control tests are the core of CCM's automated validation. Each test:

1. Contains a J1QL query that runs against your JupiterOne asset graph
2. Defines expected outcomes — whether the results returned are Compliant assets or Non-compliant assets
3. Runs automatically on a regular schedule
4. Updates the control status based on whether expectations are met

AI-Assisted Test Creation

You do not need J1QL expertise to create control tests. JupiterOne AI can generate queries from a natural language description:

note

AI-assisted query generation is available when creating a new control test. When editing an existing test, you update the query manually.

1. From a control, click New control test
2. Enter a descriptive title for what you want to test
3. Select the test type: Compliant assets or Non-compliant assets
4. Click Generate query — JupiterOne AI generates a J1QL query based on your title and the control context, and automatically runs it so you can review matching entities
5. Save the test

Mirror test creation: After you save a test, CCM prompts you to add the corresponding inverse test with the test type pre-selected. For example, if you save a Non-compliant assets test, it prompts you to create a Compliant assets test. This ensures comprehensive coverage with minimal effort.

Managing Existing Controls

From the Controls list, you can:

• Search and filter controls by status, framework, lifecycle state, or resource group
• View control details by clicking on any control
• Edit control tests to refine validation logic
• Update framework mappings to map controls to additional requirements
• Review test results to understand why a control is failing
• Assign an owner to establish accountability for each control

Control Catalogs

A catalog is a namespace for your controls. It groups controls by their origin or purpose, making it easier to organize and filter a large control library.

Examples of catalogs:

• "CIS Controls v8" — controls based on the CIS benchmark
• "Internal Security Policy" — controls defined by your organization
• "AWS Hardening" — controls specific to your AWS environment

When you create or edit a control, the Catalog field behaves like a tag selector. You can select an existing catalog or type a new name to create one. A control belongs to exactly one catalog.

Use catalogs to:

• Organize by source: Separate controls that come from different standards or internal teams
• Filter your library: Quickly find all controls within a specific catalog
• Manage at scale: When your control library grows beyond a few dozen controls, catalogs prevent the list from becoming unmanageable

Control Lifecycle

Every control in CCM moves through a defined lifecycle that provides enterprise-grade governance for your control library.

Lifecycle states:

State	Purpose
Draft	Control is being developed. This is the default state for new controls.
Review	Control is ready for validation by your team.
Live	Control is active and affects compliance scoring.
Retired	Control is no longer active but preserved for audit history.

Key behaviors:

• Only Live controls are evaluated during compliance scoring
• Every state transition is recorded in an audit trail with optional notes
• You can filter your control library by lifecycle state
• Only Live controls count toward your entitlement limits
• Controls in Draft or Review allow you to develop and validate without affecting your compliance posture

To transition a control, click the lifecycle badge on the control detail page, select the target state, and optionally add a note explaining the reason for the transition.

Integration Awareness

CCM automatically detects which integrations a control test queries and provides real-time feedback on eligibility.

• When you author a control test, the UI shows which integrations provide data for your query
• If no matching entities exist for a test (for example, you have no AWS integrations but the test queries aws_s3_bucket), the test shows No Datapoints
• Tests with no datapoints are skipped during evaluation — they do not produce false failures

This prevents confusion when a test queries data from an integration you have not configured.

Control Effectiveness

CCM provides visual status indicators so you can instantly understand whether your controls are working.

Control test statuses:

• No Datapoints — The test query returned no matching entities. This replaces false failures when data is unavailable.
• Control tests that are effective (passing) are not decorated with a special status.

Control statuses:

• No Control Tests — The control has no tests configured.
• No Datapoints — All of the control's tests lack datapoints.
• Controls with at least one passing test that has datapoints show standard pass/fail results.
• Attested — The control is covered by a valid attestation. It reports as Pass with an Attested note in the Effectiveness column. See Control Attestations.

Status rolls up from the test level to the control level, and from the control level to the requirement level. You can see at every layer of your compliance hierarchy where attention is needed.

Control Attestations

Introduced in CCM 1.4, attestations let you justify a control's compliance using evidence that lives outside its automated tests - a vendor SOC 2 report, a risk acceptance, or a manual process - for a bounded period of time. A control covered by a valid attestation is reported as Pass (with an Attested note) instead of failing, and it automatically re-fails when the attestation expires.

Use an attestation when a control is genuinely satisfied but no automated test can prove it - rather than leaving the control failing or faking a test.

Creating an attestation

From the detail page of a live control, in the Control tests and attestations section, choose Add an attestation (you need control-edit permission). An attestation captures:

Field	Description
Subject	A short title for the justification (e.g. "Vendor SOC 2 Type II report")
Description	Supporting detail, in markdown
Expiry date	When the justification lapses and the control re-evaluates
Owner	The JupiterOne user responsible for renewing it
Document link	Optional link to supporting evidence (http/https)

Attestations take effect immediately - there is no approval workflow. You can edit (renew/reassign) or revoke an attestation at any time. All create, edit, and revoke activity is retained in the audit trail independently of the control, so the record of why a control was attested survives revocation, expiry, or deletion of the control.

The combined Control tests and attestations view

A control's detail page shows a single Control tests and attestations section, with attestations listed above the control tests. A failing test always fails the control - an attestation never masks it - so the section calls out the two cases that need explaining: a control passing by attestation (a valid attestation with no contributing test), and a control failing despite an attestation (a failing test you still need to fix or archive).

This keeps the justification and the underlying test results visible together: an attestation never silently hides a failing test.

Attested status

A control that passes solely by a valid attestation - it has no contributing control test - reports as Pass, with an Attested marker in the Effectiveness column. (A control that already passes on its tests stays a plain Pass; a control with a failing test still Fails.) Attested controls:

• count as passing in framework scorecards, requirement rollups, control counts, and the daily digest;
• can be isolated with the Attested filter on the controls list, so you can always see which controls are passing by attestation rather than by test;
• are never a hidden failure - an expired attestation fails the control.

How attestations affect control status

A control's status weighs its control tests and its attestations together - an attestation never overrides a failing test. Revoked attestations are removed and never count. The result for every combination is:

Control tests	Attestations	Control status
None contributing	None (or only revoked)	Not evaluated
None contributing	At least one valid attestation	Pass (Attested)
Passing	None or valid	Pass
Failing	Any (valid or not)	Fail
Any	Any non-revoked attestation expired	Fail

The rules in plain terms:

• A failing control test always Fails the control - an attestation never masks it. To pass a control whose test is failing, fix the failing test, or archive the test if it no longer applies and let a valid attestation carry the control.
• Attested is reserved for a control that passes solely by a valid attestation, with no contributing test. A control that already passes on a test stays a plain Pass.
• If any non-revoked attestation has expired, the control Fails - even over passing tests. One lapsed justification fails the control, so an expiry is never overlooked. (Example: a control "all vendors have a current SOC 2 report" with one attestation per vendor - if any lapses, the control fails.)
• Revoking an attestation removes it; the control reverts to whatever its tests, or any remaining attestations, indicate.

Expiry and renewal

Because expiry is a time event rather than a change you make, CCM re-evaluates attested controls on a recurring schedule (within 24 hours), in addition to recomputing immediately whenever an attestation is created, edited, or revoked. A control whose only attestation lapses returns to failing automatically - even a control with no tests, which nothing else would re-evaluate.

To renew an attestation before it lapses, Edit it from the control's Control tests and attestations section and extend the expiry date. Each attestation shows its current state (active, expiring soon, expired, or revoked), so you can spot the ones that need attention.

Expiry reminder emails

CCM proactively reminds attestation owners about expiries instead of relying on them to check each control:

• Weekly attestation digest - each attestation owner receives a weekly email listing the attestations they own that have already expired (the control is failing now, shown first) and those expiring within the next 30 days (renew before the control re-fails). Every entry links to the control where you renew it, and shows the attestation's subject and expiry date. The email is sent only when an owner has something expiring or expired; revoked attestations are excluded. It also links to the Attested controls filter so you can review everything currently passing by attestation.
• Daily digests - the Control Owner and OU contact daily digests now also count the controls that are passing by attestation, so attested coverage is visible alongside the passing and failing totals.

To stop receiving reminders for an attestation, renew it (extend the expiry) or revoke it if it no longer applies.

Getting Started

Step 1: Create or Import a Framework

1. Switch to Manage mode using the toggle in the CCM navigation
2. Navigate to Frameworks under the Controls tab in the nav bar
3. Click Add a framework
4. Choose one of the following options:
   • Use Common Framework: Select an out-of-the-box CIS benchmark. If you need a framework that is not listed, click Request a new Framework to submit a request.
   • Create your own Framework: Enter a title and description to build a custom framework directly
   • Upload Your Own Framework (Beta): Import a PDF file
   • Paste Framework JSON: Manually paste JSON configuration
5. Select who has access to the framework by choosing a resource group. Resource groups control which users and groups can view and manage the framework. If you do not select a resource group, the framework is accessible to all users with CCM permissions.
6. Add requirements to your framework, each with an identifier, priority, and description

Step 2: Understand Your Control Library

1. From the Controls page, review the list of existing controls
2. Click on a control to see:
   • What it validates (control description)
   • How it validates (J1QL queries in control tests)
   • What frameworks it maps to (Requirements tab)
   • Current test results
   • Lifecycle state and effectiveness

Step 3: Create Your First Control

1. From within a requirement, click Add a control
2. Enter a title and click Draft control with AI — JupiterOne AI generates the description, remediation steps, identifier, and source catalog
3. Review and edit the AI-generated content as needed
4. Click New control test to add validation logic
5. Describe what you want to test and click Generate query — JupiterOne AI generates and runs the J1QL query
6. Review the results, then save

Step 4: Manage the Control Lifecycle

1. New controls start in Draft state
2. When the control is ready for review, transition it to Review
3. After validation, move the control to Live to include it in compliance scoring
4. Add notes at each transition for your audit trail

Step 5: Map Controls to Framework Requirements

1. From a control detail page, click the Requirements tab
2. Click Edit Requirements to add framework mappings
3. Select the framework and specific requirement(s) this control satisfies
4. Save your mappings

Step 6: Monitor and Refine

1. Return to the Overview Dashboard regularly to track control health
2. Switch to View mode to review control status and identify controls that need attention
3. Investigate non-compliant controls to understand root causes
4. Refine control test queries based on false positives or misses
5. Expand your control library to cover additional requirements

Best Practices

To maximize the value of Continuous Control Monitoring:

Start with Your Governance Framework

• Begin with controls that are already defined in your IRM or governance system
• Map those controls to framework requirements in CCM
• Use CCM to automate the evidence collection and validation for those controls

Design Effective Control Tests

• Write specific queries: Focus on precise validation criteria rather than broad checks
• Use negative tests: Often easier to detect violations (what shouldn't exist) than prove compliance
• Combine multiple tests: Use both positive and negative tests for comprehensive coverage
• Test your queries first: Run J1QL queries manually in the Query Builder before adding them as control tests
• Handle exceptions: Consider using tags or properties to exclude known exceptions from test results

Organize Controls Strategically

• Group by technology domain: Separate controls for AWS, Azure, GCP, SaaS applications
• Map to multiple frameworks: Reuse controls across frameworks where applicable
• Use consistent naming: Follow a naming convention for easier management (e.g., "5.6 (AWS) | Control Name")
• Document control intent: Write clear descriptions explaining what the control validates and why

Integrate with Your Workflow

• Connect to your IRM: Use JupiterOne's API to feed control status back to ServiceNow, Archer, or other governance platforms
• Set up alerts: Configure alerts for critical control failures that need immediate attention
• Schedule reviews: Regularly review control test results with your security and platform teams
• Track trends: Monitor control compliance over time to identify systemic issues

Scale Gradually

1. Start with 10-20 critical controls for your most important framework
2. Validate that tests are accurate and provide meaningful results
3. Expand coverage to additional frameworks and control areas
4. Refine test logic based on false positives or missed violations