Continuous Compliance

Continuous Compliance evaluates selected machine-evaluable technical controls for a configured service.

A compliant result means: this service passed the selected machine-evaluable technical controls in the configured framework profile.

What a result means

Hosted Continuous Compliance exposes only two service results:

• compliant
• non_compliant

Stored control tests are pass or fail. An expired result is shown as non_compliant with an evidence_expired blocker. Missing, stale, deleted, unverifiable, or unavailable evidence never becomes a successful unknown state.

The service is compliant only when every enabled control in the service profile has a fresh pass. Any other combination is non_compliant and includes blocker codes.

Do not describe a pass as a company certification, an application certification, or an audit opinion.

How an evaluation works

1. You declare cc.enabled: true, a framework profile, and at least one control in .drc/signal.yml.
2. drc signal cc sync reconciles those controls into the hosted workspace.
3. drc signal cc run queues a hosted evaluation. Continuous Compliance does not evaluate on the local CLI.
4. Every evaluation requires a tenant-owned finalized subject_execution_id, complete signed evidence coverage, and the exact check set for the control's test_kind.
5. The hosted worker runs the detector, records pass or fail, and derives the service snapshot.

Result: drc signal cc status shows the hosted verdict and queue. A queued control test is not a verdict.

Availability

Hosted Continuous Compliance requires Team or Enterprise. It draws from the same organization Signals minute pool as hosted Continuous Verification: 200,000 minutes at the Team 5-seat minimum, plus 25,000 minutes for each additional seat.

Team includes technical-subset coverage for SOC 2, ISO 27001, and CIS Controls v8. PCI DSS, HIPAA, and GDPR require the matching compliance pack. drc signal cc frameworks reports included versus paid entitlement for the authenticated workspace.

Profiles and coverage

Every enabled CC profile must set coverage: technical_subset. Other coverage values fail closed.

A technical subset is the machine-evaluable controls DRC can test for that framework version. It is not the full standard.

The profile also requires framework and version. Each control's framework and framework_version must match the profile.

In the workspace

Workspace Signals shows Continuous Compliance as:

• Controls — enabled machine-evaluable controls from the configured profile
• Evaluations — hosted history; results are compliant or non_compliant only
• Evidence — required evidence for those controls; expired evidence makes the service non_compliant
• Alerts — blockers that keep a service from a compliant snapshot

Controls the CLI can run

.drc/signal.yml loads only when every listed control uses a runnable test_kind with its exact required checks:

Any other test_kind fails closed with a pending-producer error. List the hosted catalog with drc signal cc controls; do not copy a catalog entry into YAML until the CLI accepts it.

Commands

drc signal cc check
drc signal cc frameworks
drc signal cc controls
drc signal cc controls --json
drc signal cc sync
drc signal cc run checkout-api
drc signal cc status
drc signal cc history
drc signal cc show <evaluation-id>

drc signal cc check validates local YAML without changing the workspace. status, history, show, frameworks, and controls read hosted state. drc signal cc controls has --json only; it does not take a framework flag.

Configure every YAML field in Signal YAML reference. For candidate-versus-baseline comparison, use Continuous Verification.